Re: [ANN] Lua 5.2.0 (work1) now available

[Roberto Ierusalimschy <roberto@...>]

> Summary:
> - Inputs to bit operations need to be converted in a consistent and
>   platform-independent way, respecting modular arithmetic requirements.

We would like to do that. But we do not know a reasonable way to do it
in ANSI C89.


> - Outputs of bit operations need to be signed.

We still dissagree. I cannot see how bit.not(0) could not be equal
to 0xffffffff. Output of bit operations should be equal to the
corresponding hexa constants. (The manual is incorrect: it should state
something along the previous line. If 0xffffffff is -1 in a specific
version of Lua, so should be bit.not(0).) In C, if you get the result of
a bit operation as a lua_Number and cast it to (unsigned int), you get
consistent results with different types of lua_Number.


> - Shift and rotate instructions need to be explicitly named.

We were already considering changing that. (But both directions will
treat a negative shift as "shift in the other direction".)


> - Shift counts should be masked by the bit width.

Not convinced (see below).


> - Arithmetic right shift is not optional.

Not sure.


> - Ignoring the naming conventions defined by the most popular
>   existing libraries is unwise, because it forces all users to
>   rewrite their code (FYI: BitOp inherited the names from lbitlib).

That was a confusion. We should use the same names.


When discussing language design, performance is always present. But
we do not think that, in a scripting language, such as Lua, we should
consider a change in an API just to avoid an extra conditional or a jump
misprediction. For LuaJIT, I am sure it will be able to eliminate
these extra tests in most cases.

-- Roberto