Re: Antwort: Re: hex numbers

["John Passaniti" <jmp@...>]

Martin Doering responded:

>>Is there any planned support for hexadecimal values for
>>the Lua language?
>
> Just write a C function for conversion from/to strings...

There is a dialect of awk from a company called Thompson Automation that
has a very handy feature I used constantly.  One of the ways they extended
awk was to allow octal and hexadecimal constants-- as in C.  So this was
valid in tawk:

     BEGIN { print 0xff + 1; }

This program would print 256.  That by itself isn't anything amazing or
unusual.  What was interesting however was that this behavior was extended
to run-time as well:

     BEGIN {
          x = "0xff"
          print x + 1
     }

Like the previous program, this also prints 256, but notice the important
difference.  Like Lua, awk allows math on numeric strings-- they are
silently coerced to numbers as necessary.  So what's happening here is the
string "0xff" is being first converted to a number and then 1 is being
added to it.  This may seem trivial, but a side effect is that any tawk
program I wrote automatically knew how to handle octal and hexadecimal
values.  For example, I wrote an assembler in tawk, and without any special
effort on my part it was able to handle octal and hexadecimal values.

This is obviously a convenience.  I certainly could have written a function
that accepts a string, parses the number, and then returns the number--
just like everyone is suggesting for Lua.  But by putting such
functionality in at the language level, you get more consistent behavior.
If you forget to wrap user input around such a conversion function, you've
got an annoying bug.

So here's a suggestion that will probably make everyone happy.  Let's take
a page from Forth.  In Forth, there is a primitive word ("NUMBER") that
interprets numbers.  Pass it a string, and it spits out the numerical value
of that string.  In many Forth implementations, such primitives can be
revectored to a new routine.  That lets the user change the conversion of
numbers if they want.  (Yes, Forth already knows how to handle various
number bases.  Ignore that fact...)

So why not do something like this for Lua?  Any time that Lua would attempt
to convert a string to a number, it should call a global function.  This
function would normally do what Lua does now-- just accept decimal numbers.
But since its a global function, it could be replaced at run-time by the
program.  So if someone wanted Lua to accept octal, hexadecimal, trinary,
base 36, or Roman numerals, it could.  And more importantly, this is
something that would work both at the language source-code and run-time
environment levels.  People who didn't want this feature would simply
ignore it.  People who wanted it would redefine the global function.
Everybody is happy!

It would likely require some (minor) changes to the lexer.  I would suggest
that a number be defined as a numeric digit followed by any length of
letters and digits.  That would allow classic C-style "0xff" and "0377"
constants, as well as more exotic Smalltalk style (number base followed by
"r" followed by the number, as in 36rSMALLTALK).  Even my goofy Roman
numerals example would be possible by putting a "0" up front:  0mcmlxvii.

The real point here isn't to support exotic Smalltalk numbers and Roman
numerals.  The point is that one of the things that makes Lua great is the
extensible semantics.  By allowing the programmer to extend how numeric
strings are converted, this suggestion is consistent (I believe) with the
Lua philosophy.