too-early feedback implementing ECMA6 array comprehension syntax

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Jun 8 17:42:43 PDT 2012


On Jun 8, 2012, at 5:21 PM, Brendan Eich wrote:

> 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:
> 
> https://mail.mozilla.org/pipermail/es-discuss/2011-September/016804.html
> 
> 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 lives.

For the benefit of those who aren't looking at the actual spec. draft, here is the current (updated to fix saurik's issue) syntax for Array Comprehension:

ArrayComprehension :
[ AssignmentExpression ComprehensionForList ]
[ AssignmentExpression ComprehensionForList  if  Expression  ]

ComprehensionForList :
ComprehensionFor
ComprehensionForList  ComprehensionFor

ComprehensionFor :
for  ForBinding of Expression 

ForBinding :
BindingIdentifier
BindingPattern  





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120608/64132ef4/attachment.html>


More information about the es-discuss mailing list