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

[Doug Currie <doug.currie@...>]

On Jan 14, 2010, at 10:01 PM, David Manura wrote:

> On Thu, Jan 14, 2010 at 6:13 PM, Miles Bader wrote:
>> I agree.  I think people almost always have a certain shift direction in
>> mind, and it's much clearer to explicitly reflect this in the code.
>> Use of negation to indicate this seems an obfuscation.
> 
> Merging lshift and rshift into one operator might be analogous to
> merging addition and subtraction, multiplication and division, sin and
> cos, etc.  We could, but we don't.

...unless we were Common Lisp programmers in another life. There, (ash x n), or bit.ashift(x, n), as it might be spelled in Lua, is defined simply as an integer x * 2^n. We let + take negative arguments, so in fact we do merge addition and subtraction in this same sense.

That said, I am not particularly advocating signed shift counts. I would be happy with them, but they seem to confuse many people. They are useful for do-it-yourself floating point: arithmetic on the exponents lead to signed shift adjustments of the mantissas. But this is hardly a typical Lua application, and can easily be implemented with a wrapper around bit.ashiftl and bit.ashiftr.

The view of arithmetic shift as an integer x * 2^n also supports the Lua authors' point of view that shift counts should not be masked. On the other hand, it is also simpatico with Mike's view that shift operands and results should be signed. 

If I had a choice between BitOp and Lua 5.2 (work2) bit libraries, I would choose BitOp for the arithmetic shift (sign preservation), signed results, and flexible (int32_t or uint32_t) operand interpretation.

e