RE: [Suggestion] Not requiring commas for table entry separation

["Peter Prade" <Peter.Prade@...>]

Joshua Jensen:
> Especially when having non-programmers create or modify these data
> files, not requiring commas is a boon.  The most common mistake is to
> simply forget to put the commas in, and then the scripts have errors.
> Some missing commas are incredibly hard to track down, depending on
> circumstances.

This is absolutely true. I made the same observation.

Joshua Jensen:
> Certainly there is an ambiguity when dealing with bracketed [key] values
> preceded by an identifier.

Peter Hill:
> And for an identifier preceeding a string, constructor, or parenthesised
> expression. Ie,
>     {f "xyzzy"} is {f("xyzzy")} or {f, "xyzzy"}?
>     {f(5+6)} is {f(5+6)} or {f, (5+6)}?

yep, those 2 problems were probably what kept the lua authors from further
simplifying the table constructors syntax.

They already listened to our input and made it possible to use a "," instead
of a ";" in a mixed constructor
(since Lua 4.1work4 you can also use {1,2,x=3} instead of {1,2;x=3}).

see also: http://lua-users.org/wiki/TableConstructors

Joshua Jensen reports:
> Certainly there is an ambiguity when dealing with bracketed [key] values
> preceded by an identifier.  For the stuff we use Lua's data description
> facilities for, this is a rarity (actually, it hasn't happened yet).

I guess this is true.
In the cases, where you want the easier syntax because non-programmers use
it to enter data, you don't have these conflicts. And in the case where you
have the ambiguity, it is probably in a table constructor entered by a
programmer, who won't mind adding seperators.

But the real problem here is when the programmer is used to omitting the
seperators in table constructors and then is entering function values in one
of his tables for the first time - this might create hard to find bugs.
(at least harder to find than a missing comma in a table constructor ;-)

Cheers,
Peter Prade