Python has requirements for over-parenthesization which we were trying
to avoid. Nevertheless, did you consider
5. Except on right of assignment and in actual argument position, yield
expressions must be parenthesized
This is easy to do grammatically if we change the over-general
ClassHeritage :
| extends| AssignmentExpression
I say over-general because: do we really want this to be valid ES6?
class D extends B = C {
}
Using a higher-precedence expression non-terminal seems better. How
about the next lower-precedence nonterminal that does not end in
AssignmentExpression, namely LogicalORExpression?
Then any yield without parentheses would be a syntax error.
/be
Allen Wirfs-Brock <mailto:[email protected]>
November 10, 2013 6:46 PM
see bug: https://bugs.ecmascript.org/show_bug.cgi?id=2011
The decision to make the AssignmentExpression optional within a
YieldExpression creates an ambiguity when combined with class
declarations. For example cosider:
function *gen() {
class Foo extends yield {}
{ }
}
Is the intent for a yield expression that yields a new object or a a
yield expression with yields a implicit undefined. Neither a human
nor a parser can know for use what the authors actual intent was.
There are several ways we could fix this problem:
1) Retract the decision to make the yield assignment expression
optional. In this case a 'yield', in all yield expression contexts,
would have to always be followed by an explicit expression producing
the value to yield.
2) Make the use of 'yield' illegal in the 'extends' clause of class
declarations. Arguably this is comparable to the restrictions on the
use of 'in' within for-in statements. This would probably not be a
major usage issue as actual use cases of 'yield' in that context seems
quite implausible.
3) Continue to allow usage of 'yield' expressions in 'extends' clauses
but make the AssignmentExpression part of the YieldExpression
mandatory in that context.
4) some other, even more ad hoc, disambiguation rule.
Either #1 or #2 would be trivial to specify. #2 would be a straight
forward use of an expression grammar parameter that we already have.
#3 is somewhat harder to specify and requires a new parameter on all
of the expression grammar productions. It would require more
editorial work to implement and result in a more cluttered grammar
definitions.
#4 needs an actual proposal that can be evaluated.
I would be happy with either alternative #1 or #2.
The actual utility of a YieldExpression in an 'extends' clause seems
so low that I don't think we should make the entire expression grammar
more complicated just to support alternative #3.
Thoughts?
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
