Re: table construction: key is string with dash

Having spent my fair share about parser construction i can say: this sort of rules are a compromise to keep parsers fast and lean. Yes it would not happen if the = was processed first, but it would mean the parser who is handling a token stream would have to do an arbitrary long look ahead. Language grammars are still designed with the parser in mind beyond theoretical unambiguousness. Especially so for Lua. As far I know, it is a single look ahead parser.

On Wed, Sep 3, 2014 at 10:07 AM, Christopher Kappe <nox_diesque@web.de> wrote:

Hello all,

I don't know if this has been discussed before or if the question is too silly but I couldn't find anything on the topic by searching google and the mailing list archive.

Concerning the construction of tables, I was under the assumption that
{ foo = bar } -- where foo is a string and bar is some variable
is the same as
{ ["foo"] = bar }
But - and that's the point of my email -
{ foo-fighter = bar }
gives an error ('}' expected near '=').

Probably the interpreter thinks that dash here is a minus operator and so foo and fighter must be number variables with a likewise numerical result of the subtraction and thus the "key-is-a-string" syntactic sugar doesn't apply. But this wouldn't happen, if the "=" sign was processed first (?).

-- No necessary information below this line ;-)
I bring this up because I really much would like to use such syntax. The background is that I like to create svg images with Lua scripts. This is easier, quicker and yields better results for me than struggling with programs like Inkscape, Draw or Dia. Especially the set of attributes for a svg tag is perfectly reflected by Lua tables. E.g. I can make a function call as
svg.rectangle{ width=100, height=42, fill="black" }
But attributes with a dash require the ugly syntax
svg.rectangle{ fill="black", ["stroke-width"]=1.337 }

So I wonder what you think. Could this kind of syntax be allowed in any later version of the language?

Best regards,
Nox