On Sep 24, 2012, at 9:00 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> The argument could validly be made for IfStatement which we cannot change,
>> for compatibility reasons. To me, if is probably mostly an issue of whether
>> we want consistency between IfStatement and comprehension if clauses.
>> consistency is good but we've already discussed that we probably don't want
>> to have Expression for if clauses because of comma confusion. I think this
>> is a discussion that could go either way, it's just good to consider the
>> full range of principles we are factoring into the decision
>
> The one distinguishing factor in the comprehension case is the paren-free
> 'if' head. IfStatement has less of an issue with comma and assignment at top
> level of the condition, although assignment is a constant worry for all
> C-family languages that allow it. GNU C has a warning for this case, you
> avoid it when you intend to assign at top level of the condition by
> over-parenthesizing:
>
> if ((yes = i_am_sure()) {...}
>
> C++ has nice binding variants:
>
> if (int yes = i_am_sure()) { /* yes in scope only here */ }
>
> and this gets '=' back in the door, but as an declaration-initializing
> operator, not the assignment operator that could be confused or typo'ed from
> ==.
>
> To loop back to your earlier point, in a comprehension:
>
> a = [e for e in set if log(e), e & 1];
>
> to log all elements in the set, but comprehend only the odd ones, looks a bit
> odd. Is that ',' separating parts of the if condition, or element
> initializers in an array literal?
>
> But there's no ambiguity here, AFAICT. See the toy grammar below. Paren-free
> heads are still bracketed in comprehensions, by 'if'/'for'/'let'/']' in full.
> Note that this would not be the case of the comprehension expression moved to
> the right.
>
> I don't believe the paren-free syntax increases the odds of typo'ing or
> otherwise mistakenly writing = for ==, so on reflection, I'm not too worried
> about comma and assignment expressions as paren-free if conditions in
> comprehensions. But I don't think it would be a big deal to forbid them
> either.
I'm not particularly concerned about the = typo issue. As you say, it's
nothing new for C-style languages. But I do think that unparenthesized
commas in comprehensions would impact the readability of code because of the
syntax sharing for object literals.
I note that in your toy grammar you avoid the comma issue at the front and in
the for clauses by using AssignmentExpression in those positions.
The current ES6 spec. draft has AssignmentExpression at the front, and
Expression in the for and if clauses. However, there is also a editor's note
that suggests that AssignmentExpression should be considered for all three
positions.
I think we should go the all AssignmentExpression route. It avoid
ArrayLiteral-like comma confusion in all three positions. It is also a simpler
set of rules to teach and remember. Finally, it leave open the future
possibility of ArrayLiterals that have comprehensions in element positions.
(not that I'm recommending this...)
Allen
>
> /be
>
> %token FOR
> %token ID
> %token IF
> %token OF
>
> %%
>
> ArrLit:
> '[' AssExpList ']'
> | '[' AssExp FOR ID OF AssExp IF Exp ']'
> ;
>
> AssExpList:
> AssExp
> | AssExpList ',' AssExp
> ;
>
> Exp:
> AssExp
> | Exp ',' AssExp
> ;
>
> AssExp:
> ID
> | ID '=' AssExp
> ;
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
