lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> I already asked the opinion of Lua Team about this when work2 came
> out, I got some remarks from lua-l members, but I got no "official"
> response, so I dare bump it up.
> A couple of features I'd like to see implemented would be:
> 1. Binary literals, such as 0b100101101, or something like that.
> 2. A non-significant digit separator (say "_") for better
> readability of long numbers:
> 1111_222_333_4444 would be parsed (lexed?) as 1111222333444,
> of course banning the underscore from the beginning and the end.
> Even more useful for 64bit hex literals or binary literals (if implemented):
> 0xaabef_bee1_1230_aabb
> 0b1001_1100_1111_001_1_111
> (useful when representing some register or binary data structure layout).
> The digit separator thing seems almost zero-cost (skip a char in the
> lexer, I guess). Binary literal may be a little more expensive, but
> since tonumber already handles the translation in the language,
> maybe some code reuse under the hood could make this change very
> lightweight.
> Do Lua Team think they could be added to a next version? I think the
> convenience is very high (now that "bit fiddling" in Lua has been
> graced with 64bit ints and binops) with very few drawbacks.

First, we disagree that the convenience is "very high". (I would
give it at most a "medium". :-) Of course, for some people it may be
the most important feature of the language, but this is true for almost
anything that people ask. (It is also important to measure the
convenience as compared with the alternatives already presented
in previous discussions.)

Also, the costs are not as low as it sounds. Among other points, we have
to consider the following:

- Should "tonumber" also support these features? (If so, the
implementation is not as trivial as it sounds.)

- Should"n") support them? (Again, more work ahead.)

- If Lua is going to support binary numerals, shouldn't it have some way
to print them? ("%b" in string.format is more work, specially if we are
going to support flags, width, and precision, like the other formats.)

(Not to mention that binary numbers could also ignite the anger of
octal-lovers :-)

-- Roberto