Allen Wirfs-Brock wrote:
> On Nov 11, 2013, at 12:51 AM, Brendan Eich wrote:
>
>> >  Allen Wirfs-Brock wrote:
>>>>> >>>  >    Yep -- I'm warming up to LeftHandSideExpression. It allows new and call forms, member expressions, primary expressions, but not unparenthesized ternary, binary or unary operators -- and (crucially for the bug) not anything ending in AssignmentExpression. Allen?
>>>>> >>>  >  
>>> >>  
>>> >>  Playing devil's advocate for the movement.  Sure, general Expression
>> >  
>> >  You must mean AssignmentExpression -- no ES6 draft allows comma expressions after extends.
>
> Yes, my recollection is we wanted to leave open the possibility that comma in the extends clause might, in the future, have special meaning.

We have problems with paren-free heads for if, while, etc. because 
statement bodies need not be braced in the paren-ful case:

https://mail.mozilla.org/pipermail/es-discuss/2011-September/016804.html

I don't see a similar problem here, yet, but it's a possibility. If 
class body always starts with { and no expression can adjoin a braced 
form and make a larger expression, we're ok. This prohibition must be 
kept in all future editions.


>> >  Hardly any programmers, in the first place, will write any ternary, binary, or unary operator expression after extends.
>
> No, I think you're missing the point.  Of course, most programmers will never even consider writhing anything more complex than a function call in the extends clause.  But the extra complexity of having restricted expression forms in some places does add to the overall conceptual burden on programmers.

You're just repeating your assertion as its own proof here. Sorry, it's 
not an axiom.

"Most programmers" do not think about grammar in this level of detail.

If your grammar parameterization only prohibits unparenthesized yield at 
the end of the extends RHS, that may be worth the ugliness in the spec.

But first let's make sure we aren't going wrong in allowing arbitrary 
AssignmentExpression after 'extends'. The paren-free gotcha needs 
another look.

/be

Allen Wirfs-Brock wrote:

> Yes, my recollection is we wanted to leave open the possibility that comma in the extends clause might, in the future, have special meaning.

We have problems with paren-free heads for if, while, etc. because 
statement bodies need not be braced in the paren-ful case:

https://mail.mozilla.org/pipermail/es-discuss/2011-September/016804.html

I don't see a similar problem here, yet, but it's a possibility. If 
class body always starts with { and no expression can adjoin a braced 
form and make a larger expression, we're ok. This prohibition must be 
kept in all future editions.


> No, I think you're missing the point.  Of course, most programmers will never even consider writhing anything more complex than a function call in the extends clause.  But the extra complexity of having restricted expression forms in some places does add to the overall conceptual burden on programmers.

You're just repeating your assertion as its own proof here. Sorry, it's 
not an axiom.

"Most programmers" do not think about grammar in this level of detail.

If your grammar parameterization only prohibits unparenthesized yield at 
the end of the extends RHS, that may be worth the ugliness in the spec.

But first let's make sure we aren't going wrong in allowing arbitrary 
AssignmentExpression after 'extends'. The paren-free gotcha needs 
another look.