Why are table literals treated differently from table references in Lua?

Question

Here is a Lua 5.2.2 transcript, showing the declaration and indexing of a table:

> mylist = {'foo', 'bar'}
> print(mylist[1])
foo

Why isn't the following statement legal?

> print({'foo', 'bar'}[1])
stdin:1: ')' expected near '['

I can't think of any other language where a literal can't be substituted for a reference (except, of course, when an lvalue is needed).

FWIW, parenthesizing the table literal makes the statement legal:

> print(({'foo', 'bar'})[1])
foo

score 12 · Accepted Answer · edited Nov 12 '13 at 20:37

12

It is also related to the fact that in Lua this syntax is valid:

myfunc { 1, 2, 3 }

and it is equivalent to:

myfunc( { 1, 2, 3 } )

Therefore an expression such as:

myfunc { 1, 2, 3 } [2]

is parsed as:

myfunc( { 1, 2, 3 } )[2]

so first the function call is evaluated, then the indexing takes place.

If {1,2,3}[2] could be parsed as a valid indexing operation it could lead to ambiguities in the previous expression that would require more lookahead. The Lua team chose to make the Lua bytecode compiler fast by making it a single pass compiler, so it scans source code only once with a minimum of lookahead. This message to lua mailing list from Roberto Ierusalimschy (lead Lua developer) points in that direction.

The same problem exists for string literals and method calls. This is invalid:

"my literal":sub(1)

but this is valid:

("my literal"):sub(1)

Again, Lua allows this:

func "my literal"

as equivalent to this:

func( "my literal" )

edited Nov 12 '13 at 20:37

Ellen Spertus

6,576
9
50
101

answered Oct 12 '13 at 08:39

LorenzoDonati4Ukraine-OnStrike

6,875
4
37
56

+1; this actually explains the reason. I'm no friend of the `foo"bar" => foo("bar")` syntactic sugar though. – dualed Oct 12 '13 at 17:28
1

@dualed Well, if its only use were for avoiding a pair of parens, I'd agree, but the true power of that "sugar" is apparent when designing domain specific languages. For example, something like `Widget { w = 100, h = 10} "Warning" "stack overflow in the frobnicator!"` is regular Lua syntax and can be "parsed" by the `Widget` function using some closure trickery very easily, without the need to write a parser! This can be very handy when using Lua as a configuration language or for other applications where end users are not skilled programmers, or to create custom data description languages. – LorenzoDonati4Ukraine-OnStrike Oct 12 '13 at 17:37
1

I strongly disagree, this kind of stuff only confuses a user, especially if they make some mistakes. The error message would never make sense to them. Ever. Safer to use plain Lua syntax, some existing plist, xml, ini, you name it or even create your own and write a real parser for it. – dualed Oct 12 '13 at 18:48

HennyH · Answer 2 · 2013-10-12T07:50:00.507

Going of the grammar defined here, the reason that the non parenthesized version is invalid yet the parenthesized is, is because the syntax tree takes a different path and expects a closing bracket ) because there should be no other symbol in that context.

In the first case:

functioncall ::=  prefixexp args | prefixexp `:´ Name args 

    prefixexp =>
        prefixexp ::= var | functioncall | `(´ exp `)´

            var -> print
    THEREFORE prefixexp -> print

    args =>
        args ::=  `(´ [explist] `)´ | tableconstructor | String 
            match '('

            explist =>
                explist ::= {exp `,´} exp
                    exp =>
                        exp ::=  nil | false | true | Number | String | `...´ | function | prefixexp | tableconstructor | exp binop exp | unop exp
                            tableconstructor => 
                    explist-> {'foo','bar'}

            THEREFORE explist = {'foo','bar'}

            match ')' ERROR!!! found '[' expected ')'

On the other hand with parenthesis:

functioncall ::=  prefixexp args | prefixexp `:´ Name args 

    prefixexp =>
        prefixexp ::= var | functioncall | `(´ exp `)´

            var -> print
    THEREFORE prefixexp -> print

    args =>
        args ::=  `(´ [explist] `)´ | tableconstructor | String 
            match '('

            explist =>
                explist ::= {exp `,´} exp
                    exp =>
                        exp ::=  nil | false | true | Number | String | `...´ | function | prefixexp | tableconstructor | exp binop exp | unop exp 
                            prefixexp =>
                                prefixexp ::= var | functioncall | `(´ exp `)´
                                    var => 
                                        var ::=  Name | prefixexp `[´ exp `]´ | prefixexp `.´ Name 
                                            prefixexp =>
                                                prefixexp ::= var | functioncall | `(´ exp `)´
                                                match '('
                                                exp => 
                                                    exp ::=  nil | false | true | Number | String | `...´ | function | prefixexp | tableconstructor | exp binop exp | unop exp 
                                                    tableconstructor => 
                                                THEREFORE exp = {'foo','bar'}
                                                match ')'
                                            THEREFORE prefixexp = ({'foo','bar'})
                                            match '['
                                            exp => Number = 1
                                            match ']'
                                    THEREFORE VAR = ({'foo','bar'})[1]
                            THEREFORE prefixexp = VAR
                    THEREFOER exp = VAR
            THEREFORE explist = VAR
            match ')'
    THEREFORE args = (VAR)
=> print(VAR)

Thanks for the explanation and pointing me to the grammar. Any idea why they didn't create the grammar in the more usual way, getting rid of prefixexp and moving its RHS into exp? My guess is that they were trying to catch errors like '3[2]' at parse-time instead of at run-time. — Ellen Spertus, Oct 12 '13 at 07:39
I find it fitting that I was bit by a language designed for beginners rather than experienced programmers, since I've worked on creating languages (such as App Inventor for Android) that were intentionally designed to surprise the experienced programmer rather than the beginner whenever someone had to be surprised. For example, like Lua, App Inventor uses 1-based lists. — Ellen Spertus, Oct 12 '13 at 07:42
@espertus I'm not sure why they decided on having it this way, you may be right about it catching errors beforehand. I actually encountered this **exact** problem before and thought (after coming from lots of python) *what? why doesn't think work*. — HennyH, Oct 12 '13 at 07:45

Why are table literals treated differently from table references in Lua?

2 Answers2