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

["Joshua Jensen" <jjensen@...>]

> 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.

Arguably, maybe whitespace should make a difference.  I had even
forgotten about the {f "xyzzy"} syntax translating to {f("xyzzy")}.

In any case, there are ambiguities, but in resolving the ambiguities,
the syntax becomes more complex for the simple situations.  I can't tell
you the number of times I've had to help somebody find their missing
comma.  Commenting out huge portions of the Lua data file is often
necessary to isolate it.  Likewise, if:

f = 5

and you punched in the data:

{ f "xyzzy" }

_I_ would have expected (as would the non-programmer) the final result
to be:

{ 5 "xyzzy" }

And that makes it even more obvious why the commas are required (as
unfortunate as that may be for the simple data description case).  I use
Lua as a replacement for languages like XML.  It's overall cleaner
syntax and more powerful description capabilities (IMHO) make it way
easier to describe the data.

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

Agreed, although a dump of the table contents to a text file would
probably make it pretty obvious what entries were wrong.  Still, I would
fully expect one of the programmer/non-programmer types to do the {
globalValue "This is a string" } syntax when describing their data.  So,
catch-22.  The syntactic sugar for { function "argument" } makes a few
things easier to read (although I typically see scripts from the Lua
authors like { function"argument" }).  However, the simplicity of not
requiring commas is also really nice.

Thanks,
Josh