Re: future of annotations in Lua?

[Hisham <h@...>]

On Fri, 7 Jun 2019 at 05:11, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
>
> 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).

The ambiguity here comes from attempting to apply an annotation to a
value rather than a variable. Perhaps the confusion arose from the
`@annotation function` example, but even though functions are values,
that annotation is binding to a variable: `function x()...` in Lua is
a variable declaration, shorthand for `x = function()...`. With
annotations applied to variables rather than values, the @ syntax is
not ambiguous, even with parameters. (The <> syntax would be equally
problematic to apply to values.)


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