Re: Lua string library partially reimplemented in Lua

[Mike Pall <mikelu-0809@...>]

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 -).
- A new literal syntax is needed, since 255 and 0xff must stay
  numbers.
- 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.

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.


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.

--Mike