 |
lua-l archive |
|
|
||
|
Lisa Parratt wrote:
Treating an int as 32 bits indexed from 0-31 is just an optimised representation of a table. Let's not elevate that optimisation to the status of discrete mathematics. Personally I find that about half the time when I want to use bitfields I end up overflowing the 32-bit ceiling anyway (in C this is), so you have to use non-basic types anyway.Erik Hougaard wrote:Numbers are floats/doubles ;-)Only in the out of the box configuration - it's an exceedingly minor change to move over to integers. Personally, I'd like to see more primitive arithmetic support. I intensely dislike the fact you're basically forced to resort to C in order to perform discrete mathematics, one of the cornerstones of computation.
Now I'd certainly support more user-extensible operators, I hinted as much in my "move towards Common Lisp" suggestion. ML and Icon both provide interesting references here. The big problem I see for Lua with any sort of extensible syntax is that currently compilation of Lua (into bytecodes, or runtime functions) does not depend on the Lua environment. Which makes offline compilation easy.
Returning to the particular suggestion, it is of course possible to define the meaning of the bitwise operators without reference to an underlying representation: For example ~x === -x-1. Essentially any bitwise operation gets converted to a series of arithmetical operations, which are equivalent when viewed as operating on a infinite bit-string (a signed integer can be represented as an infinite bit-string with either a finite number of 1s (positive) or a finite number of 0s (negative)). Whether the underlying arithmetic then takes places using 64-bit ints, 32-bit floats, or bit-strings becomes a quality of implementation issue. That might be a good idea.
drj