lua-users home
lua-l archive

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


Your proposed use of ":" is ambiguous as well because it is funcamentally a binary operator:

- it is a creating a "functor" type object between a pair of objects (the first one being the object to give to the first parameter of a function call, the second one being the identifier of one of its members) and that functor is then followed by one additional parameter (a single unary _expression_) or by zero or more additional parameters (in a list of arbitrary expressions)

As such, your syntax:

{} :table

is ambiguous if the annotation it is not surrounded by parentheses (including the first token ":"):
{} (:table)
{} (:table 64, 68)



Le sam. 8 juin 2019 à 07:56, Egor Skriptunoff <egor.skriptunoff@gmail.com> a écrit :
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)

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 :-)