index of literal tables.

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

index of literal tables.

Axel Kittenberger
local season = 's'
...
local text =
   ({
       s = 'summer term',
       w = 'winter term'
   })[ season ]

Why do I need brackets around the curly brackets?

Why is

local text =
   {
       s = 'summer term',
       w = 'winter term'
   }[ season ]  

not valid?

Its no deal breaker, so I do brackets. But I just wonder...

Kind regards, Axel
Reply | Threaded
Open this post in threaded view
|

Re: index of literal tables.

Matthias Kluwe
Hi!

2014-05-14 10:46 GMT+02:00 Axel Kittenberger <[hidden email]>:

> local season = 's'
> ...
> local text =
>    ({
>        s = 'summer term',
>        w = 'winter term'
>    })[ season ]
>
> Why do I need brackets around the curly brackets?
>
> Why is
>
> local text =
>    {
>        s = 'summer term',
>        w = 'winter term'
>    }[ season ]
>
> not valid?

I think the syntax says so:

   var ::=  Name | prefixexp ‘[’ exp ‘]’ | prefixexp ‘.’ Name

and

    prefixexp ::= var | functioncall | ‘(’ exp ‘)’

Here, the expression in `exp` (being a table constructor) requires the
parentheses.

(Or: Because. I once noticed this too, but I was never inclined to ask why...)

Regards,
Matthias

Reply | Threaded
Open this post in threaded view
|

Re: index of literal tables.

Rena
In reply to this post by Axel Kittenberger

On 2014-05-14 4:47 AM, "Axel Kittenberger" <[hidden email]> wrote:
>
> local season = 's'
> ...
> local text =
>    ({
>        s = 'summer term',
>        w = 'winter term'
>    })[ season ]
>
> Why do I need brackets around the curly brackets?
>
> Why is
>
> local text =
>    {
>        s = 'summer term',
>        w = 'winter term'
>    }[ season ]  
>
> not valid?
>
> Its no deal breaker, so I do brackets. But I just wonder...
>
> Kind regards, Axel

I don't know the exact reasoning, but I'll note that these also won't work:

{f=print}:f()

"hi":upper ()

Both cases also require parens.

Reply | Threaded
Open this post in threaded view
|

Re: index of literal tables.

Matthias Kluwe
Am 14.05.2014 17:33, schrieb Rena:

> On 2014-05-14 4:47 AM, "Axel Kittenberger" <[hidden email]
> <mailto:[hidden email]>> wrote:
>>
>> local season = 's'
>> ...
>> local text =
>>    ({
>>        s = 'summer term',
>>        w = 'winter term'
>>    })[ season ]
>>
>> Why do I need brackets around the curly brackets?
>>
>> Why is
>>
>> local text =
>>    {
>>        s = 'summer term',
>>        w = 'winter term'
>>    }[ season ]  
>>
>> not valid?
>>
>> Its no deal breaker, so I do brackets. But I just wonder...
>>
>> Kind regards, Axel
>
> I don't know the exact reasoning, but I'll note that these also won't work:
>
> {f=print}:f()
>
> "hi":upper ()
>
> Both cases also require parens.

As required by the syntax.

I guess this has been done to simplify the grammar, or ease the parsing.
Perhaps there is some unwanted ambiguity when this was allowed. When you
have a plausible reason, this might be added to one of the FAQs...

[You don't want to propose a change to the language, do you? :-)]

Regards,
Matthias


Reply | Threaded
Open this post in threaded view
|

Re: index of literal tables.

Axel Kittenberger
[You don't want to propose a change to the language, do you? :-)]

Given the easiness to workaround it, there are certainly more worthwhile things to concentrate efforts on ;-)

I was just wondering, despite having some dejavu that years ago that already surprised me about Lua. The thing why it catches my attention was because of my experiences with PHP. When I learned that mycall( )[ 0 ] did not work its way through the parser, I thought, what kind of nonsense language is that? ;-)




On Wed, May 14, 2014 at 6:51 PM, Matthias Kluwe <[hidden email]> wrote:
Am 14.05.2014 17:33, schrieb Rena:
> On 2014-05-14 4:47 AM, "Axel Kittenberger" <[hidden email]
> <mailto:[hidden email]>> wrote:
>>
>> local season = 's'
>> ...
>> local text =
>>    ({
>>        s = 'summer term',
>>        w = 'winter term'
>>    })[ season ]
>>
>> Why do I need brackets around the curly brackets?
>>
>> Why is
>>
>> local text =
>>    {
>>        s = 'summer term',
>>        w = 'winter term'
>>    }[ season ]
>>
>> not valid?
>>
>> Its no deal breaker, so I do brackets. But I just wonder...
>>
>> Kind regards, Axel
>
> I don't know the exact reasoning, but I'll note that these also won't work:
>
> {f=print}:f()
>
> "hi":upper ()
>
> Both cases also require parens.

As required by the syntax.

I guess this has been done to simplify the grammar, or ease the parsing.
Perhaps there is some unwanted ambiguity when this was allowed. When you
have a plausible reason, this might be added to one of the FAQs...

[You don't want to propose a change to the language, do you? :-)]

Regards,
Matthias



Reply | Threaded
Open this post in threaded view
|

Re: index of literal tables.

Thomas Jericke


-----Original Message-----
From: "Axel Kittenberger" <[hidden email]>
To: "Lua mailing list" <[hidden email]>
Date: 15-05-2014 14:47
Subject: Re: index of literal tables.

> [You don't want to propose a change to the language, do you? :-)]

Given the easiness to workaround it, there are certainly more worthwhile things to concentrate efforts on ;-)

Well I added this change to my patch as well. So my syntax patch seems to work, but know I am thinking if there are some other redundant brackets I could get rid of.
--
Thomas
Reply | Threaded
Open this post in threaded view
|

Re: index of literal tables.

Sven Olsen
In reply to this post by Axel Kittenberger
I don't know the exact reasoning, but I'll note that these also won't work:

I suspect it has to due with semicolons. Because Lua doesn't have a required "end the statement" token, there's always a chance of bugs due to syntax ambiguities.  Specifically, you'll get in to trouble with lines like:

(f or g)()
(h or g)() 

Lua's string and table function call shorthand both terminate the statement they're a part of when they're evoked. Which means there's no ambiguity here:

(f or g) {}
(h or g) ()

Well I added this change to my patch as well. So my syntax patch seems to work, but know I am thinking if there are some other redundant brackets I could get rid of.

Be aware that if you patch the parser to allow suffix expressions that immediately follow tables or string literals, the meaning of vanilla Lua code may change.  See specifically the preceding code, which used to parse as 2 statements, though now it's just a single one (and a likely bug).

As an occasional parser hacker, I've been down this road myself.  By my best recollection, I think it may be possible to get really clever, and tweak the parser to only allow table and string suffix expressions in cases where doing so does not expand the set of possible syntax ambiguities -- i.e., to write a version of the table/string suffix patch that's guaranteed to be backwards compatible.  The diff would get considerably bigger though -- and it seems like a lot of work for a minor feature.

-Sven