lua-users home
lua-l archive

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


Such use of a "b" function would collide with two many unrelated uses of a local variable or parameter named "b".

Note that even if you can declare constants, in a relevant context where ther's no collision with a function "b" (so that the function won't be called many times, functions are still not declarable as "pure" in Lua, meaning that their evaluation wit the same parameter values will always return the same value (without side effect from their environment), and so that such functions calls can be cached (in implicitly declared local temp variables), or refactored by the Lua compiler (e.g. moved out of a loop).

We should be able to declare a function as being pure, but the Lua compiler could also determine it itself, if it sees that the function code does not depend on its calling environment (note that any subcall to an external library or to other functions in the same context would make it impure, unless the subcalled functions themselves are pure.

If the compiler determines some code that is "purely functional", it can easily refactor it, including with dead code elimination, or preevaluation of common subexpressions at compile time without any performance cost at run-time (it would be useful when there are debugging configuration using constants in a header, that can be easily modified in the source, or when those constants come from an environment that the function itself cannot alter: Lua would itself behave at compiler time like a preprocessor... but at the price of a possibly longer compilation time; the compiler would intrindicaly generate local temporary variables).

Local temporary variables could then only be initialized once, possibly lazily if they are fist initialized to an internal tracking reference to a hidden object (whose first dereference would execute the bound function call to compute its value, and then never written again; and that variable could be persistant for simple value types, or weakly persistant for complex value types like object references: the garbage collector may eventually dispose it and reset it to the initial tracking object that would force the _expression_ to be computed again to rebuild that object).


Le mer. 26 janv. 2022 à 11:09, Tomas Mudrunka <mudrunka@spoje.net> a écrit :
> There is nothing wrong with this approach, quite the opposite. Just
> two details:
>
> - You can write b'00101010' instead of b('00101010').
>
> - You can use 'tonumber' to do the conversion.

Thanks for your insight, i will use this wrapper (tostring() is optional
or even redundant) as a workaround:

function b(str); return tonumber(tostring(str),2); end;

>
> About performance, as with most constants in programs, it is good
> practice to predefine them, so that these conversions are done
> only once for each constant.
>
> -- Roberto

Exactly. That is why i think it would make sense to have support for
binary literals directly in Lua.

To make it clear i use Lua embedded in C software to provide some
flexibility and scripting to users. The overall design is such that
there is no place for user to predefine constants outside of the Lua
script which gets called from C loop quite often including such base
conversion in each cycle. So i think it would be bit faster if this gets
converted when script gets parsed (or compiled) rather than during
execution.

Also it seems it would make sense to keep the syntax symmetric. eg.:

0xFF and 0b11111111
rather than
0xFF and b'11111111'

That just triggers my OCD :-)

--
S pozdravem
Best regards
      Tomáš Mudruňka - SPOJE.NET s.r.o.