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" <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
