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. 

> 
>>  allows for odd and probably useless things in an extends clause but so does a ParenthesisedExpression so it isn't clear that the LHSExpression restriction really gives JS programmers anything  if there is some other way to fix the yield bug.  But what the LHSExpression restriction does do is make the language conceptually more complex for programmers.
> 
> No, "for programmers" is not an abstract claim you can make based on grammar details, it depends on what "most programmers" expect and *actually use*. Class head syntax for most programmers is not considered a place to put arbitrary expressions, e.g., involving && or * / % or unary+/-.
> 
> The idea that programmers will face complexity in not being able to write
> 
>  class MyWidget extends objWithValueOf + haha { ... }
> 
> and instead have to write
> 
>  class MyWidget extends (objWithValueOf + haha) { ... }
> 
> is silly. 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.  


> 
> The tiny fraction who might write such code would need parentheses. That's a good thing, for readability, IMHO.
> 
>> Currently Statement and Declaration forms consistently only use Expression or AssignmentExpression as component elements.
> 
> The extends clause's RHS is not a "component element".
> 
>>   And, AssignmentExpression (with one exception, which I think may be a bug.  separate issue...) is only used in contexts where there would be a comma based ambiguity.  So, taking the language as it stands now, there is really only one concept of expression that JS programmers have to learn and think about when composing JS statements.
> 
> You are inverting how programmers write code. They do not think "what does the grammar generally allow?" and then write the widest form that parses.
> 
>> Restricting the expression in the extends clause of a class definition to LeftHandSideExpression would mean that there is another "top-level" expression form that is used somewhere in the statement grammar.   It's quite likely that some JS programmer will be taught about this but only remember that most places you can use a general expression but some places you can only use some restricted expression form. For that point forward, they may be questioning themselves anytime they write an expression: Is this a place where I have to restrict which operators I use?
> 
> It's quite likely? Evidence?

Evidence to the contrary?  I'll cite personal experience.  I find that when I'm using (particularly on a casual basis) a language with lots of rules, exceptions, and inconsistencies that I'm frequently have thoughts like "is this kind of expression allowed here?"

The concern isn't that when somebody needs to do something like:
   class extends (isBinary? Float64Array : Array) {
that they will need to remember to use parenthesis.  The concern is that because this restriction exists it may cause them to think about whether they need parenthesis many other places. 


> 
>> If we go that route we are trading-off conceptual simplicity against some grammar complexity that most programmer will never see and that only only restricts the YieldExpressions syntax in a manner and place that nobody probably will ever encounter.  While it would need to be documented in reference material, no one would really need to be taught about the yield value expression being required in extends clauses.
> 
> No, see below.
> 
>> Finally, turns out that restricting the optional yield AssignmentExpression only requires additional parameterization of three productions: Expression, AssignmentExpression, and ConditinalExpression.
> 
> That's enough to be a minor blight, and worse, you are now forbidding someone from writing a class declaration *or expression* in a generator, and using yield to send a value in as the base class to extend. Why?

I'm not sure what you are saying.  They only restriction I had in mind was that the expression within the extends clause could not end with the keyword 'yield'.

You couldn't say:
   class extends yield {constructor() {...

but instead would have to say
   class extends (yield) {constructor() {...
or
   class extends yield undefined {constructor() {...

> 
>> So, from a conceptual simplicity and consistency perspective, I think it may be better to go with alternative #3 (require AssignmentExpression in YieldExpressions in extends clauses).
> 
> You argument from expected grammar is backwards and doesn't make sense. Meanwhile, a send into a
> 
>  yield class extends (yield) { ... }
> 
> in a generator would be denied for no good reason. And you've crudded up the grammar with a parameterized check that is not otherwise needed.

see above, not what I'm saying. 

> 
> I think it's time for the devil to yield, no pun intended.

Actually,  in the past I have suggested exactly such a LHSExpression restriction in various places (including computed property keys and perhaps even in the extends clause) and the committee push back was that such restrictions were generally undesirable...

Allen



> 
> /be
>

On Nov 11, 2013, at 12:51 AM, Brendan Eich wrote:

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


> No, "for programmers" is not an abstract claim you can make based on grammar details, it depends on what "most programmers" expect and *actually use*. Class head syntax for most programmers is not considered a place to put arbitrary expressions, e.g., involving && or * / % or unary+/-.
> 
> The idea that programmers will face complexity in not being able to write
> 
>     class MyWidget extends objWithValueOf + haha { ... }
> 
> and instead have to write
> 
>     class MyWidget extends (objWithValueOf + haha) { ... }
> 
> is silly. 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.  

> It's quite likely? Evidence?

Evidence to the contrary?  I'll cite personal experience.  I find that when I'm using (particularly on a casual basis) a language with lots of rules, exceptions, and inconsistencies that I'm frequently have thoughts like "is this kind of expression allowed here?"

The concern isn't that when somebody needs to do something like:

    class extends (isBinary? Float64Array : Array) {

that they will need to remember to use parenthesis.  The concern is that because this restriction exists it may cause them to think about whether they need parenthesis many other places. 

> That's enough to be a minor blight, and worse, you are now forbidding someone from writing a class declaration *or expression* in a generator, and using yield to send a value in as the base class to extend. Why?

I'm not sure what you are saying.  They only restriction I had in mind was that the expression within the extends clause could not end with the keyword 'yield'.

You couldn't say:

    class extends yield {constructor() {...

but instead would have to say

     class extends (yield) {constructor() {...

or

    class extends yield undefined {constructor() {...


> You argument from expected grammar is backwards and doesn't make sense. Meanwhile, a send into a
> 
>     yield class extends (yield) { ... }
> 
> in a generator would be denied for no good reason. And you've crudded up the grammar with a parameterized check that is not otherwise needed.

see above, not what I'm saying. 

> I think it's time for the devil to yield, no pun intended.

Actually,  in the past I have suggested exactly such a LHSExpression restriction in various places (including computed property keys and perhaps even in the extends clause) and the committee push back was that such restrictions were generally undesirable...