{ 1 } [1] vs ( { 1 } ) [1]

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

{ 1 } [1] vs ( { 1 } ) [1]

Viacheslav Usov
Using Lua 5.3.

Code:

return { 1 } [1]

Result:

<eof> expected near '['

Code:

return ( { 1 } ) [1]

Result:

1

The question is, why is the first version not accepted? I am not
asking for an explanation why the details are such and such, but
rather for a rationale, if there is one, that a table "literal"
(constructor) should not appear in some expressions unless it is
wrapped in parentheses.

Especially when we consider that there is special syntax for a table
"literal" in a function call that dispenses with parentheses.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: { 1 } [1] vs ( { 1 } ) [1]

Francisco Olarte
On Thu, Jan 14, 2021 at 6:30 PM Viacheslav Usov <[hidden email]> wrote:
> The question is, why is the first version not accepted? I am not
> asking for an explanation why the details are such and such, but
> rather for a rationale, if there is one, that a table "literal"
> (constructor) should not appear in some expressions unless it is
> wrapped in parentheses.

Well, it is not accepted because the grammar says so ( prefixeps,
which is what you can index, are not general expressions ). And the
grammar probably says so to simplify the parsing, although the lua
team may have some thing to say on this. Probably for the same reason
you cannot use the : operator on string literal and some other
oddities, it complicates implementation, is not too useful and can be
easily done with just some parentheses, does not pull its weight.

> Especially when we consider that there is special syntax for a table
> "literal" in a function call that dispenses with parentheses.

IIRC the string / table literal are there to simplify use of lua in
DSLs and similar stuff, it may have been deemed worth some parser
complication. You find a lot of cases when you try to pile up things
in lua compared to other languages, probably due to it having a 1 page
grammar.

Francisco Olarte.
Reply | Threaded
Open this post in threaded view
|

Re: { 1 } [1] vs ( { 1 } ) [1]

Roberto Ierusalimschy
In reply to this post by Viacheslav Usov
> Using Lua 5.3.
>
> Code:
>
> return { 1 } [1]
>
> Result:
>
> <eof> expected near '['
>
> Code:
>
> return ( { 1 } ) [1]
>
> Result:
>
> 1
>
> The question is, why is the first version not accepted? I am not
> asking for an explanation why the details are such and such, but
> rather for a rationale, if there is one, that a table "literal"
> (constructor) should not appear in some expressions unless it is
> wrapped in parentheses.

For regularity, what can come before [exp] is the same stuff that
can come before (explist), forming function calls. Allowing {1}[1]
would also allow {1}(1), which being a function call could be
used as a statement:

  a = b
  {1}(1)     -- "calling" table {1}

That would create another ambiguity in the grammar, similar to the
(already present) ambiguity with parentheses:

  a = b
  (print)(1)     -- calling print or calling b?

We chose to reduce ambiguities.

Note too that all other "literals" also cannot be used in that position:

  4[1];  "hello"[1];  true[1];  nil[1]

But, in the end, it all boils down to taste.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: { 1 } [1] vs ( { 1 } ) [1]

Thomas Jericke-2
Am 14.01.2021 um 20:30 schrieb Roberto Ierusalimschy:
Using Lua 5.3.

Code:

return { 1 } [1]

Result:

<eof> expected near '['

Code:

return ( { 1 } ) [1]

Result:

1

The question is, why is the first version not accepted? I am not
asking for an explanation why the details are such and such, but
rather for a rationale, if there is one, that a table "literal"
(constructor) should not appear in some expressions unless it is
wrapped in parentheses.
For regularity, what can come before [exp] is the same stuff that
can come before (explist), forming function calls. Allowing {1}[1]
would also allow {1}(1), which being a function call could be
used as a statement:

  a = b
  {1}(1)     -- "calling" table {1}

That would create another ambiguity in the grammar, similar to the
(already present) ambiguity with parentheses:

  a = b
  (print)(1)     -- calling print or calling b?

We chose to reduce ambiguities.

Note too that all other "literals" also cannot be used in that position:

  4[1];  "hello"[1];  true[1];  nil[1]

But, in the end, it all boils down to taste.

-- Roberto

I made a patch for Lua 5.2 to make those brackets optional. To be backwards compatible, I excluded that call operator.

You find that patch here.

http://lua-users.org/wiki/ThomasJericke

My basic idea back than was to have type notation similar to UML notation:

163764 : uint32 would than create a uint32 userdate that stores 16376, this by registering all conversion function to the metatable of the type number. I never continued the approach as I don't think that breaking compatibility to vanilla Lua is worth the benefit of an arguably nicer syntax.

--

Thomas