Re: future of annotations in Lua?

[Philippe Verdy <verdy_p@...>]

with surrounding parentheses around "complex" annotations, we have much more freedom to choose the first token: not only we can use binary operators (that are not also unary operators) like ":", ".", "*", "<", but we can also reuse other existing keywords such as:

  (if _expression_) {}

which is another kind of annotation similar to some preprocessor condition applied to the unary _expression_ "{}" that follows it, possibly extended to:

  (if expression1, else error) {}

which adds an "else" parameter to the "if" annotation, also as an annotation with parameter "error", so the "if" has two parameters: "expression1" and "else error"

This can be used for example to perform platform-specific optimizations:

  (if target.platform~='i386', else asm 'pushf; pop ax') flags()

This means that the "flags()" _expression_ is annotated by a conditional "if" annotation that checks if the target.platform is 'i386' and replaces in that case the _expression_ by the assembly code, also given by another annotation, "asm" which takes in parameter a string that it will compile...

As well this can be used to add anotation for debuggers by inserting a "break" annotation taking in parameter some possible expressions useful for the debugger

  (break) {}

  (break"my breakpoint") {}

Le ven. 7 juin 2019 à 10:12, Philippe Verdy <verdy_p@wanadoo.fr> a écrit :

And if someone does not like the "@", we can still use the proposed "*":

  (*table 64) {}

Here also the inner parentheses surrounding the parameters of the annotation are removed, exactly and consistantly with the currification of regular function calls.

Le ven. 7 juin 2019 à 10:10, Philippe Verdy <verdy_p@wanadoo.fr> a écrit :

Le jeu. 6 juin 2019 à 23:35, Lorenzo Donati <lorenzodonatibz@tiscali.it> a écrit :

On 06/06/2019 22:41, Hisham wrote:
> A pattern in Lua's history is that some features appear first as a
> special-case feature that solves a narrow set of problems, and are
> later generalized into a broader mechanism.
>

[snip]


> If the door is to be left open for such a generalized mechanism in
> future versions of Lua beyond 5.4, then adopting a syntax based on an
> unused token such as @annotation would be advisable. Matching the
> annotation syntax of other languages would be a side benefit.
>
> -- Hisham
>
>

I fully agree!

As I wrote in another thread (in a sub-sub thread - urgh! this 5.4 thing
is stirring lua-l quite a lot :-) compare:

local <toclose, static, nice, helpful, wonderful> resource = ....

vs.

local @toclose @static @nice @helpful @wonderful resource = ....

and also regarding code hard wrapping:

local < toclose, static,
   nice, helpful, wonderful > resource = ....

vs.

local @toclose @static
   @nice @helpful @wonderful resource = ....

The more I think about it, the more I find the syntax with "@" more
readable and more easily "expandable": parametrized annotations anyone?
Like for example:

local @const myTable = @table(64) {} -- preallocates 64 elements in the
array part

The syntax "@table(64){}" is ambiguous, it can be thought of the annotation "@table" for the _expression_ 64, which is the right handside of a binary operator (a function call).

Consider: "@table(t){}" ...

The only way is to surround annotations with parameters by parentheses:

  (@table(64)) {}

but we can also drop the unnecessary inner parentheses for the parameters of the annotation itself:

  (@table 64) {}