lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 08/06/2019 07:55, Egor Skriptunoff wrote:
On Fri, Jun 7, 2019 at 12:35 AM Lorenzo Donati wrote:


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





Please note that Lua lexer allows inserting a space between any two
lexems. For example, the following is allowed in Lua syntax: ::
labelname :: x = math . pi goto labelname

My question is: if an attribute name and an opening parenthesis are
distinct lexems (and there could be a space or a newline in
between), then what is the pure syntactical way to determine where an
attribute is terminated?

Your example: local myTable = @table(64) {}

Variant1: "@table(64)" is the attribute "{}" is the expression

Variant2: "@table" is the attribute "(64){}" is the expression: you
are invoking number 64 and pass empty table as argument :-)

It seems that for your example to work Lua parser should know every
attribute to determine whether it expects parameters or not. It would
be more correct if Lua could parse both known and unknown attributes
in the same way without knowing their semantics. It's funny, but
angle-bracket-based syntax works here without ambiguity problems:
local myTable = <table(64)> {}

So, both <attribute> syntax and @attribute syntax are not
"suitable". But an example of a "suitable" syntax could be easily
constructed: @[table 64] or @(table 64). They are both "equal", but I
prefer the last one. To make parameterless attributes look nicer, two
syntactical forms may be allowed: @attributename              -- for
attributes without arguments @(attributename arguments)  -- for
attributes with arguments The "attributename" is simple or
dot-separated compound identifier (such as "Torch.Tensor") The
"arguments" is a comma-separated list of Lua expressions, similar to
a list of arguments for a function's invocation. For example, to
preallocate a table with 64 array slots and 8 hash slots: local
@const myTable = @(table 64, 8) {} The @const attribute might also be
written as @(const) if you wish.

Such syntax guarantees unambiguous parsing everywhere: in local
definition, in function definition, inside any expression, etc.


P.S. Why @[table 64] and @(table 64) are "suitable", but @<table 64>
is not? Because of incompatibility with Lua expression syntax:
@(table a>b and a or b)  is OK @<table a>b and a or b>  is not OK


P.P.S. Prefix-ish and postfix-ish approaches are just a mirror of
each other. Neither is better than another.

local @Torch.Tensor z = @Torch.Tensor x + @Torch.Tensor y
(@Torch.Tensor z):abs() local @integer c = (@deterministic
add)(@integer a, @integer b) local @const myTable = @(table 64, 8)
{}

local z :Torch.Tensor = x :Torch.Tensor + y :Torch.Tensor (z
:Torch.Tensor):abs() local c :integer = (add :deterministic)(a
:integer, b :integer) local myTable :const = {} :(table 64, 8)



OOF! Nice points. Thanks!

Anyway I didn't think too well to other possible sources of ambiguities
when I "spat out" my suggestion, so it's nice you fleshed them out so
thoroughly.

Your @(attribute parameters) syntax looks quite well, IMO, and gets my
point through: it is a possible future enhancement and the "@" makes it
much less prone to confusion with other language constructs

The only difference between these two approaches is the occurrence of
the sad smile in the last line. Lua syntax should not contain any
sadness :-)


I fully agree!!! :-)