Teal Playground URL: https://686--teal-playground-preview.netlify.app

@fperrad One concern I had originally was that there were some semantics differences between bit and bit32 (I don't remember the details, but I remember some significant arguments between Mike and Roberto in lua-l back in the day), so my rationale was that sticking with bit32 meant that the Teal operators would have the most similar semantics regardless of targetted VM (modulo inevitable differences between 32 and 64 bit numbers). Any thoughts on this point?...

I'm not 100% sure that there are no semantic differences now, but am unaware of anything but syntax differences. I've been using this bitshim module to provide a normalized syntax that can be driven by either bit, bit32, or the new operators in Lua 5.3+.

@alerque There are. This thread contains at least one example and more info (with posts from Roberto and Mike Pall) http://lua-users.org/lists/lua-l/2010-10/msg00286.html

The difference described by David Manura in that post still applies:

] luajit
LuaJIT 2.1.0-20220411 -- Copyright (C) 2005-2022 Mike Pall. https://luajit.org/
JIT: ON SSE3 SSE4.1 BMI2 fold cse dce fwd dse narrow loop abc sink fuse
> print(bit.lshift(0xffffffff, 32))
-1

] lua
Lua 5.3.6  Copyright (C) 1994-2020 Lua.org, PUC-Rio
> bit32.lshift(0xffffffff, 32)
0

For completeness, Lua 5.4 gives a totally different result, but that's understandable since it's a 64-bit "platform", numbers aren't expected to behave the same anyway:

] lua5.4
Lua 5.4.4  Copyright (C) 1994-2022 Lua.org, PUC-Rio
> 0xffffffff << 32
-4294967296

I expect that Teal does its best effort, not to try to solve incompabilities/inconsistencies between various version of Lua.

At the end point, when I work on a module targeting the Lua ecosystem, I believe in the test suite that I run on every Lua version/configuration (thanks to Hererocks). I don't believe on a magical tool.

From my point of view:

• targeting PUC Lua 5.1 or 5.2 has few interest because users have already shifted to 5.3 or 5.4,
• targeting LuaJIT has an interest because users cannot move and LuaJIT will never support bitwise operators (and others 5.3/5.4 features)

@fperrad what Teal currently does is my best effort. ;)

It is not trying to be magical. Perhaps the difference is that you may be looking at Teal as a Lua-code-generating-tool. I look at it as a programming language. As a language, it has its own semantics, which are my responsibility to define (or to leave undefined — or in the words of the great Neil Peart, "if you choose not to decide, you still have made a choice").

Authors of Teal libraries will be writing Teal code and getting one given semantics for a given number size. It's fair to assume that Teal module authors will expect that consumers of their libraries will get the author-intended semantics wherever they run their code.

On a more personal note, one of the things that do annoy me in the Lua ecosystem are the myriad small inconsistencies across versions. I've spent many years writing LuaRocks code that keeps walking on eggshells to be able to run on every relevant Lua version; I'd rather not have to — I want to have one semantics I know, code for that, and have it "just work". This was probably the secondary motivation for Teal (the first one being type-checking). That's also why it loads the compat libraries by default.

I am still reluctant about adding a mode that makes the bitwise operators generate lua-bitop, but if we do add that, it would have to be a flag of its own, and definitely not the default target mode for Lua 5.1. After all, IIRC lua-bitop can be compiled and used with other Lua versions too. I also don't want to associate it to --gen-target=luajit, because the generation target shouldn't alter the language semantics (modulo unavoidable changes such as integer size).

I hope you understand these concerns of mine are coming from a place of responsibility regarding the stewardship of the language, rather than any preference between bit32 and lua-bitop!