 |
lua-l archive |
|
|
||
|
On 18/12/2018 17:28, Roberto Ierusalimschy wrote:
The workaround has already been explicitly shot down in this thread: it's a runtime transformation which means you take a performance hit every time you use one. It HAS to be done at the lexer level to be practical for anything that needs to worry about scalability. This plus binary literals are things that have been in demand for quite a while and they're things I think are worth doing -- though they're things that can be done with token filters, too.Up to a point. In Java, the "thousand separator" can only be used in source code; methods to convert strings to numbers do not accept them. I am not sure this would be a good design for a scripting language like Lua. On the other hand, to accept thousand separators in floating strings like 'tostring("123_527.24")' is not as easy as to simply ignore the separators in the lexer. Binary literals also pose some design questions: - Of course, 'tonumber', 'io.read("n")', and similar functionality should support that format. - Shouldn't Lua have a correspondent format to print binary numbers? (To implement a simple '%b' is quite easy; something that handles '%-#080.3b' is not that easy.) - Should Lua also support floating binary literals? -- Roberto
Interesting points.I wouldn't care about FP /binary/ literals. Probably FP /hex/ literals are enough and Lua wouldn't benefit too much from the former.
Integer binary literals are a different beast, IMO. Maybe I'm biased because I'm doing lot of works with microcontrollers lately, and writing down bit-patterns in code using hex is not as clear as using binary, especially when dealing with lots of MCU registers.
OK, an expert gets used to it, but as a (high school) teacher I usually write example code that should help students understand the inner working of the thing, and there is a limit to what a newbie can grok about such low level stuff, and binary notation would help a lot!
In this respect a %b format should also be defined, even if not handling every possible option available for (e.g) %x (anyway, the implementation could be incremental: start with basic options, then expand the features in new Lua releases).
For now I use C or C++ for firmware code, but I'm planning to try to use eLua in the future (on the long run), or even Lua-proper if I manage to do something with more powerful MCUs.
Anyway, I do use Lua for toy programs showing what bits operations do in practice, but for this I use my own routines to handle binary representation (no need to be efficient here!:-).
BTW, I wonder whether PUC-Lua could be easily adapted to MCUs in a freestanding environment. I mean, if the MCU has enough RAM, could Lua be ported to such an environment without the need of an OS? I know that eLua was heavily modified IIRC to cope with small MCUs constraints (too little RAM). Will having much more RAM allow using PUC-Lua without so much hassle? Maybe is the Harvard architecture of many MCU also a problem for PUC-Lua's C code?
Cheers! Lorenzo.