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:
