[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: "Ignore me" symbol
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Thu, 20 Dec 2018 20:58:50 +0100
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?
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?