lua-users home
lua-l archive

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


On 03/06/2022 13:52, Sergey Zakharchenko wrote:
Hello list,


Hello!

One of Lua's greatest strengths is its hackability. It's possible to
add custom opcodes and operators representing them, but in doing so,
we break source-level compatibility. What if we could have a
universal and familiar syntax representing the operations? Here's
what I have on my mind:

------------------------------------------------------------ In BNF:
edit

prefixexp ::= var | functioncall | ( exp )

to read

prefixexp ::= var | functioncall | ( exp ) | ` ( exp )

In expression documentation, add:

`(exp) is equivalent to exp, but possibly optimized in an
implementation-specific manner.
------------------------------------------------------------


[snip]


All feedback welcome!


I'm very wary of any syntax change that hampers readability and is not related to clearly defined semantics.

If we want highly optimized code we have C, with all its hassles regarding unspecified, implementation-defined and undefined behavior, where implementations are free to define (and document) undefined behavior as an extension! And all that pesky sequence-point rules.

And Lua was designed from the start with C integration in mind.

Now what would `(exp) mean exactly? Would it be just a hint that something *might* be optimized by the current implementation? Or is it an explicit request like "*do* optimize this if you can" to the implementation?

Does it change the semantics? No? So why would the programmer care? Why wouldn't the programmer want a more optimized code? Maybe because there are drawbacks? Is it really useful to let the programmer simply say "optimize" or "not optimize", without knowing explicitly what is happening?

What if there are different level of optimizations with different tradeoffs? Memory vs speed, maybe? How could the programmer say "optimize at level 2, but not at 3 in this case"?

At this point the programmer should really be able to *choose explicitly* what he needs. Again, this seems the realm of C, or of explicitly calling different implementations of a Lua function.

Expression-level optimizations is something an implementation should tackle, and only if it is generally useful. Lua already optimizes some expressions (e.g. repeated use of ".." operator), but IIRC it doesn't have a general bytecode optimizer (like some C compilers do at assembly level, where they exploit all the leeway the standard gives to implementations).

In the end, your proposal seems to have very limited usefulness in general (IIUC: just when you have two possible options where the programmer may need to make an informed choice about a possible optimization that is not "tunable").

OTOH, this breaks one of the best practices of high level programming and SW engineering: hiding implementation details. And what is more "implementation-detaily" than an optimization?

And it hampers readability too. What if I want to optimize only a subexpression? Would something like the following be valid?

x and `(type( x ) == 'number') and `(myfunc(z))

And what happens to this code when you run the program in another implementation that does *different* optimizations?

Again, the code gets obfuscated and the only advantage is very context specific.

Of course there are times when a programmer wants to know something about the efficiency of an algorithm (e.g. is this function O(1) or O(n)?), but if one is using Lua for fine-tuning efficiency IMHO they are on the wrong path: they should use the C-API instead and *document extensively* any function that they make available on Lua side and document each call site stating *why* it is important that the specific call is a call to a heavily optimized function.

What you propose could be obtained more simply as:

function test(x,y,z)
-- optimized algorithm, maybe implemented in C in some implementations;
-- regular code in non-optimized implementations.
end

-- Call site:

if test(x,y,z) then ....


If the overhead of the function call is excessive wrt the execution time of the body of the function, this would call for (pun intended) a general change of Lua VM where function calls could be inlined (IDK if current Lua implementation inlines some calls).



Best regards,

-- DoubleF


Cheers!

-- Lorenzo