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

["Peter Hill" <corwin@...>]

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

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

I'd *like* to not need a comma... afterall I'd like to be able to wrap a
list of global assignments, eg:
    x = 1
    y = 2
into a table constructor
    {
    x = 1,
    y = 2,
    }
without having to add the commas.

But there is some serious ambiguity here :-(. Otoh, this is the same problem
that statements face with the (up until recently) optional ";" separator. It
is handled thusly:

(a) ["if"] = "token"
This format (though a consistent & useful way to access globals) is
prohibited. Instead one must use something like: _G["if"] = "token".

If constructors used a consistent style they would instead use something
like: X = {_SELF["if"] = "token"}. Hey, it might actually be nice to have
access to _SELF inside a constructor (allowing self-referential tables)
although anonymous functions don't currently have that luxury.

Alternately, one could just use a different non-index syntax for evaluated
table assignments. Eg, the rather ugly:
    X = {@"if" = "token"}
and
    @"if" = "token"

(b) f "" AND (c) f {}
Unlike inside a constructor, where values are always meaningful, statements
are not interested in return values. As such the statement expression syntax
is restricted to 'procedure calls' only, so the above cases are not a
problem. Otoh that does help 'procedure calls'...

(d) f (1+2)
It doesn't handle this. An explicit ';' is required to separate the terms so
';' is no longer optional :-(. That's confusing enough, but having similar
optional (unless required) syntax for commas in constructors would be a
naive user's nightmare. There must be a better way to keep consistency :-(.



*cheers*
Peter Hill.

PS:
Joshua Jensen said (16th Feb):
> Subject: Non-stop complaining...
> And on a very personal note, the conversations I think clog the list are:
(snip)
> * Syntax issues

AND

Joshua Jensen said (17 Feb):
>  Subject: [Suggestion] Not requiring commas for table entry separation

Huh?!?! You've got me confused now 8-O.
Are 'commas' an ok non-clogging "syntax issue" but inband operating system
filetype information creeping in to Lua code in the guise of comments
aren't? ;-)