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