Re: Generic optimizable operation syntax proposal

[Paul Ducklin <pducklin@...>]

Given that you will need your own compiler to generate your own this-is-not-actually-Lua bytecode…

…then why would your compiler need these weird syntactic hints mixed into the source code?
 
If your compiler isn’t smart enough to figure out for itself when to generate code to use your new-and-improved operators, then it’s not doing its job properly. (Or your new operators aren’t really an improvement.)

Also, how would programmers signal which of possibly many non-standard Lua compilers they were trying to “assist” when they added backticks to their code? How would each modified compiler know which backtick markup was relevant to its specific new operators and optimisations? (And if it could figure it out for itself, why would it need the backtick markup in the first place?)


> 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