too-early feedback implementing ECMA6 array comprehension syntax

Brendan Eich brendan at
Fri Jun 8 17:21:39 PDT 2012

Allen Wirfs-Brock wrote:
> On Jun 8, 2012, at 3:58 PM, Brendan Eich wrote:
>> Allen Wirfs-Brock wrote:
>>> It may well be that the initial Expression of the ArrayComprehension productions should be an AssignmentExpression  in order to avoid commas.
>> This is just a draft-spec grammar bug. What I implemented in SpiderMonkey many years ago is what is grammatically necessary: AssignmentExpression. Otherwise you have not only a readability problem as Jay wrote, but a real problem in top-down parsers deciding whether you are in an array initialiser or array comprehension. Bottom up parsers can cope but practical implementations are all top-down.
> What do you think about the expression following the of or if of a comprehension,

[<assign-expr> for ( <pattern> of <expr > ) if (<expr>)]

is an informal way to grammar. As in for-of loops and if statements, we 
want Expression. This is what SpiderMonkey and Rhino implement, but of 
course not paren-free.

>   assuming we are going to be paren-free.  Both can be in a trailing position within a comprehension.  I don't think there are any parsing issue with them, but they represent similar readability issues:
>    [ i for i of foo, bar]
>    [i for i of foo if i!=="bar", false]
> Assignment expression would eliminate that reability issue.  Of course, so would mandatory parrens.

Good to discuss both options, even though we'd be diverging from the for 
and if statement sub-grammar in this regard if we use <assign-expr> not 
<expr>. But let's talk about paren-free heads first. That is not a slam 
dunk in my view, since Waldemar cited code-under-maintenance hazards 
with paren-free in general that made me vow to go back to do "paren-free 
redux" that included more newline signfiicance.

In comprehensions, newlines are not common and can't help. OTOH 
comprehensions are restrictive enough that the hazards under maintenance 
that Waldemar cited:

do not obviously arise. In a comprehension, there's always a 'for' or 
'if' always-reserved keyword separating successive parts, unlike in the 
'then'-free C-style 'if' statement with a paren-free head and no 
mandatory braces around the consequent.

But even before we seek further hard cases, perhaps we should agree that 
paren-free heads in comprehensions and generator expressions are a goal 
for ES6. We could defer along with paren-free in full, get on with our 


More information about the es-discuss mailing list