Removal of NoIn grammar productions and for-loop parsing

Erik Arvidsson erik.arvidsson at gmail.com
Mon Sep 2 07:05:06 PDT 2013


How is this different than destructuring assignment? We need a cover
grammar in this case too.
On Sep 1, 2013 10:42 PM, "Brendan Eich" <brendan at mozilla.com> wrote:

> Another item from the day of the July meeting that I happened to miss.
>
> Allen Wirfs-Brock wrote:
>
>> However, at the meeting, we did not discussion the fact that in ES3 NoIn
>> was also used in:
>>
>> IterationStatement : 'for' '(' [ExpressionNoIn]   ';'  [Expression]  ';'
>> [Expression] ')' Statement
>>
>> This makes statements like this:
>>
>> for (a in b ;;) ;
>>
>> illegal in ES3.  This was presumably done for nanny reasons
>>
>
> No, not for nanny reasons.
>
>  as using the 'in' operator in this position isn't ambiguous. The
>> availability of the NoIn productions also made it easy to express such a
>> restriction.
>>
>
> Consider this toy grammar:
>
> %token FOR
> %token IDENT
> %token IN
> %token NUMBER
>
> %%
>
> Program:
>         Statement
> |       Program Statement
> ;
>
> Statement:
>         FOR '(' Expression ';' Expression ';' Expression ')' Statement
> |       FOR '(' Expression IN Expression ')' Statement
> |       Expression ';'
> ;
>
> Expression:
>         Expression IN Primary
> |       Primary
> ;
>
> Primary:
>         NUMBER
> |       IDENT
> ;
>
> This grammar is ambiguous: as bison(1) says,
>
> state 18
>
>     6 Expression: Expression IN Primary .
>     7           | Primary .
>
>     IN        reduce using rule 6 (Expression)
>     IN        [reduce using rule 7 (Expression)]
>     ')'       reduce using rule 7 (Expression)
>     $default  reduce using rule 6 (Expression)
>
> See attached file for full output.
>
>
>  But if we eliminate the NoIn productions it's no longer so easy to impose
>> that restriction.  I may be able to come up with some other static semantic
>> mechanism to express that restriction but it will have complexity similar
>> to the NoIn productions.
>>
>
> You can'd do this via static semantics, as I said in my last message. We
> need an LR(1) grammar, that was always a consensus requirement.
>
>  My preference is to simply allow the use of the 'in' operator in the
>> first expression of a for(;;) statement.
>>
>
> Ambiguity is not a matter of preference. We need to validate the ES6
> grammar. Until then, please put back the NoIn productions. They were not
> there only because of the silly and unwanted initialiser option for 'for
> (var x = y of z)'. They were there because for-in and for(;;) have prefixes
> in common up to arbitrary lookahead.
>
> /be
>
>
>   This is what the rev17 grammer does.  As it is currently illegal in
>> ES<=5.1,  allowing 'in' use in that context is an extension rather than a
>> breaking change. 'a in 'b may not be very useful in that position but
>> neither is 'a + b'.  The simplification of the expression grammar is a
>> pretty big win both now and for future extensions.
>>
>> Allen
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130902/21e85487/attachment.html>


More information about the es-discuss mailing list