Re: Generic optimizable operation syntax proposal

[Lorenzo Donati <lorenzodonatibz@...>]

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