Nannying (was: Array comprehension syntax)

[Allen Wirfs-Brock]

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
> ;
>