The dot would not work well for _expression_ keys that are numbers or start by numbers !
See: t = {.1 = 1, ..2 = .2, .-3 = -3, .1+x = 1+x}; and consider how the lexer could need to parse ".1" as "." then "1", where the lexer cannot convert ".1" into a number constant (same as 0.1)
Trying to use a dot instead of [] would not help the parser, it would complicate it more, we would have to force a space after the dot.
See: t = {. 1 = 1, . .2 = .2, . -3 = -3, . 1+x = 1+x};
In reality when the syntax was developed, there was the need to allow optional keys, so members could be any _expression_ as a value, including an _expression_ being only a single identifier for a variable name (so there's a "reduce" case here for the parser, which can only be followed by a comma or a closing brace or any other operator valid in an _expression_. But with the optional key present, the single identifier (before the "=" sign) could be also a key so there's a "shift" case for the parser. The shift-reduce conflict is resolved here by forcing a "shift", but if we use the lookahead of one token, the shift-reduce conflict after an identifier is resolved: if the identifier followed is followed by a single equal sign (which is illegal in expressions) then this is a shift, so this indicates the presence of a key: so {x=1} is allowed.
The [] around keys does not help at all the parser.
But then if the parser admits a single identifier as a key, it could as well admit admit a number as a key, including a number with a leading sign.
It could as well accept any _expression_ as a key, reporting to later the decision to the presence or absence of the equal sign: the _expression_ can be only followed by:
- a comma (separating members of the table constructor, in which case the _expression_ is unambiguously a value without any key), or
- a closing brace (terminating the table contructor,
in which case the _expression_ is
unambiguously
a value without any key), or
- an equal sign (in which case the _expression_ is
unambiguously a key and the parser can shift the equal sign to parse the second _expression_ that should follow)
Lua authors made a strange choice: adding [] that was not needed at all, but then accepting that [] was not necessary for literal string keys, rewritten as identifiers instead of a literal string.
Overall the table constructor is not bad.
One source of mistake for me is that when I see a name=value in the table constructor, the name looks like a variable to me, not a literal string, because any hint is missing: no quotes, no dot
Instead of T = { x=1, y=2 }
I would strongly prefer T = { .x=1, .y=2 }
the Dot is the hint that this is equivalent to T = { [“x”]=1, [“y”]=2 }
if there is no dot, each item in the constructor could be an _expression_ (value) or exp=exp (key=value), there would be no square brackets
T = { a=b } would be same as T = { [a]=b } Where a is a variable holding the key and b is another variable holding the value
But if you look at it, the absence of square brackets may make more difficult to immediately catch the key when reading the code
I mean square brackets make keys very different with respect to values and that is good, is not it?
I have not studied the current parser, maybe there is a good reason to have mandatory square brackets to indicate a key _expression_?
Maybe this make the parser simpler and faster?
Or square brackets could be eliminated as suggested above? (When there is no dot expkey=expval or just expval, with the dot .key=val)
Andrea
--
