Re: Generic optimizable operation syntax proposal

[Sergey Zakharchenko <doublef.mobile@...>]

Hello Lorenzo,

Lorenzo Donati <lorenzodonatibz@tiscali.it>:
> I'm very wary of any syntax change that hampers readability and is not
> related to clearly defined semantics.

The semantics should be rather clear. `(exp) is exp, as far as
semantics is concerned. Readability is partially addressed by using `
and not e.g. $.

> If we want highly optimized code we have C

There still are some use cases for which a C function call might still
be too expensive. Otherwise the bitwise operators wouldn't have been
added. The tricky part is that not everyone agrees on the exact set of
those use cases.

> 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?

The latter.

> Does it change the semantics? No? So why would the programmer care?

A programmer encountering such an expression could think "the author
believes this is some sort of an idiomatic form of expression that has
some well-defined function on its own and will be used many times".

> Why
> wouldn't the programmer want a more optimized code? Maybe because there
> are drawbacks?

Because the Lua parser uses only a single lookahead token and only
occasionally. Optimizations like those discussed need more. Patching
the parser for each possible sequence, adding backtracking, etc. would
be more cumbersome.

> 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"?

If this really becomes a concern, which I doubt, the load function
flags could control that as well.

> 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))

It would (why wouldn't it?).

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

That's the point. Another implementation will still be able to parse
and run the program in (semantically) the same way (at least that's my
intent).

> they should use the C-API instead

I'll just state this one more time and won't get back to this: a
bytecode-level operator is faster than a Lua API C function call doing
the same (you seem to agree on this further though).

> 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).

If I understand you correctly, the amount of changes necessary would
likely be larger (you would need to change the Lua C API, and would
still need parser lookahead changes).

Best regards,

-- 
DoubleF