lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]
The big difference between bitfields and numbers is overflow; bitfields do overflow, numbers shouldn't.
This has been an issue with LNUM patch (which gives graceful transition from integer range to floating points, instead of integer overflow).
Also, I think the issue with enums and bitfields is the same. They are alike.
There is an old "enum patch" somewhere on the net; currently it is not possible to make "family aware" enums without patching Lua. What we'd need is either a "semi-light userdata" (pointers, but with metatable) or a dedicated enum type.
Support for "__typeof" or similar metafield would also be good; this has been separately discussed on the list. 

...more below...


Mike Pall kirjoitti 20.9.2008 kello 19:17:


Mark Meijer wrote:

This may seem like a weird question... but is it actually necessary
for a variable used as a field of bits, to have a valid representation 
as a (lua)number, and to be able to convert between the two? In other
words, what exactly justifies treating a bit field as a number, or a
number as a bit field? Especially if the value of a bit field (when
interpreted as an integer datatype - which could be considered an
implicit cast) has a different representation from the same value as a 
lua number (i.e. usually a double).

Perhaps bit fields should be treated more as an opaque "type", only
allowing operations to set and clear specific bits by means of the
usual bitwise operators. This may be limiting in some ways, but it
probably also means much simpler semantics, and no unnecessary
conversion issues.


Your thoughts are certainly spot on from a theoretical standpoint.
But IMHO there's too much overlap between the practical use cases
to justify an extra data type:

- The source and the destination of bit operations need to be
 a number in many cases. E.g.:
   y = t[band(i, 15)]    -- With i a numeric loop variable.
   s2 = string.char(band(string.byte(s1), 15))
- You'll probably need to support most arithmetic operations on
 bit types, anyway (at least + and -).


No, you wouldn't.  Give an example?



- A new literal syntax is needed, since 255 and 0xff must stay
 numbers.
How about enums (bitfield values) only coming from C code. This way, extension modules could 
	a) create an enum family	(say SDL_SURFACE_TYPE)
b) push bitfield values that belong to that enum family (are of its type)
If there's need, there could be an "anonymous enum" function 'enum(255)' for creating a blank bitfield of 0xff value. 

Blank bitfields are seldom if ever needed.



- The C API would need to be extended to handle the bit type.

In short: explicit conversions would be rather inconvenient and
implicit conversions render the type distinction meaningless.
The only conversion needed would be automatic -> string conversion for output, and maybe ':int()' or ':value()' for getting the numeric value of the enum. 




Of course there are difficulties that arise when doubles are used
to hold bit fields. But this is more of an implementation problem,
and not much of an issue in practical use. And it doesn't cause a
performance problem -- you won't notice it in the interpreter and
the compiler can avoid most conversions.
The strongest reason I feel Lua needs enums, is ability to more closely -and safely- present C library API's. Current stock answer is to make options strings. Really? 



Yes, this discussion is ignoring the need for arbitrary-length bit
fields. An extra data type certainly makes sense for this. And I
may add one later.

But ... the actual demand for 'simple' bit operations for Lua is
*much* higher. And most people are ok with the 32 bit limitation.
The plethora of powerpatches or libraries and the sheer number of
complaints on the mailing list should be reason enough.
If Lua authors give a teeny weeny tiny bit of support, I'll wrap the enum patch so that it's offering all of this, in "non-core" Lua space. 

-asko




--Mike