On Nov 10, 2013, at 5:45 PM, Brendan Eich wrote: > Mark S. Miller wrote: >> >> >> Another way to go is far higher precedence, say >> LeftHandSideExpression? That avoids all arithmetic operators, >> unary and binary. >> >> >> If we go with the highest plausible precedence, we can always lower it >> later. Not vice versa. > > 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 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. Currently Statement and Declaration forms consistently only use Expression or AssignmentExpression as component elements. 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. 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? 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. Finally, turns out that restricting the optional yield AssignmentExpression only requires additional parameterization of three productions: Expression, AssignmentExpression, and ConditinalExpression. 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). Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
