Re: Generic optimizable operation syntax proposal

You went a bit into the details and I wasn't able to follow you. But I think I understand your basic idea.

One use case might be to have an optimized time symbol that is tied to a PTP clock. Maybe this would be faster than using a required library and that could be significant in applications that make decisions based on that clock? If that is not a correct example, can you correct that or give another example of a use case where this might be useful?

On Fri, Jun 3, 2022 at 6:53 AM Sergey Zakharchenko <doublef.mobile@gmail.com> wrote:

Hello list,

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

E.g. print(`(fn())) would be equivalent to print(fn()) (and, in
particular, NOT to print((fn()))).

The no-op implementation of the above should be trivial. Actual
optimization-capable implementations could be larger, require larger
lookahead, etc. but could encode typical operations as
implementation-specific opcodes with no need to expose them on the
source level. Therefore, such implementations would be
source-level-compatible.

In general, such optimizations could be questionable, e.g.
`(type(a)=="number")) needs 'type' to be accessible and point to the
real 'type', which may not be the case (you never know what's in that
_ENV). Therefore, they need to be explicitly enabled at load (parse)
time, by conditional compilation, or something like:

------------------------------------------------------------
In load function documentation, add:

The string 'mode' may contain '`(...)' where characters inside the
parentheses indicate implementation-specific optimization parameters
(significant only if the mode string contains 't').
------------------------------------------------------------

All feedback welcome!

Best regards,

--
DoubleF