Re: optional yield expression creates ambiguity
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
On Nov 12, 2013, at 9:27 AM, Brendan Eich wrote:
...
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.
...
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.
The { is a mandatory part of the class declaration syntax, not part of the
class body. In that regard, it is more like:
CaseClause :
'case' Expression ':' StatementList
which has a mandatory delimiter after the Expression, then it is like
IfExpression and friends that have an undelimted Statement as their tail.
But the message you referenced above is more about refactoring/editing hazards
so lets look at those types of hazards with 'extends' AssignmentExpression
Assume we start with
class foo extends bar {}
If somebody added an binary operator after 'bar' but forgot to add its right
operand
we would have
class foo extends bar+ {}
The braces would be interpreter as an object literal that was part of the
expression. But the class body braces are still mandatory so if the next
meaningful line starts with anything other than a { we have a syntax error (and
one that ASI can't fix).
Assuming the program was syntactically valid before inserting the + the only
thing that could be on the next line starting with a { is a Block.
If the following Block was empty it would be interpreter as the class body and
the program would parse correctly. Of course, a runtime error will occur when
the extends expression evaluates to a non-function (but perhaps if 'bar' was a
value object with operator overloading, the + might evaluate to a function, but
it still seems unlikely).
If the following Block looked like this:
{f(a) /*ASI here */
{/*any Valid StatementList */}
}
the ClassDeclaration would also parses correctly using the following Block as
the class body. EG,
class foo extends bar+ {}
{f(a) /*no ASI here in a ClassBody*/
{/*any Valid StatementList */}
}
Note that the hazard of this occurring is essentially the same as if somebody
inadvertently inserted a '+' after the 'foo()' in:
foo() /*ASI here */
{f(a) /*ASI here */
{/*any Valid StatementList */}
}
except the class declaration case still has the runtime check that the
'extends' expression evaluates to a function.
My conclusion from the above is that 'extends' AssignmentExpression, assuming
we fix the 'yield' ambiguity, doesn't introduce any editing/refactoring hazards
that don't already exist for common ES language constructs and my impression is
that those hazards don't appear to be significant issues for developers using
the current language.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
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.
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.
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?
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?
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.
I think it's time for the devil to yield, no pun intended.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
Is await really the right syntax? Even with a higher precedence, await is a prefix operator and thus does not chain well. Typical code is array.asyncMap(f1).asyncFilter(f2).asyncReduce(f3) await forces you to write something like: await (await (await array.asyncMap(f1)).asyncFilter(f2)).asyncReduce(f3) A postfix, or even better, infix, operator plays much nicer. For example, the concurrency strawman ! proposal: array!asyncMap(f1)!asyncFilter(f2)!asyncReduce(f3) I've been writing lots of code like this with streamline.js: array.asyncMap(_, f1).asyncFilter(_, f2).asyncReduce(_, f3) A little more verbose and hackier than the ! operator but it chains well. This makes a big difference in usability. Bruno ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
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
optional yield expression creates ambiguity
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
On Sun, Nov 10, 2013 at 1:46 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: 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. It would be possible to just parenthesize the YieldExpression if you actually wanted one in an extends clause, right? Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
yes On Nov 10, 2013, at 11:04 AM, Sam Tobin-Hochstadt wrote: On Sun, Nov 10, 2013 at 1:46 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: 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. It would be possible to just parenthesize the YieldExpression if you actually wanted one in an extends clause, right? Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
On Nov 10, 2013, at 11:12 AM, Allen Wirfs-Brock wrote: yes sorry, answered without thinking enough. If we want alternative #2 to allow (YieldExpression) even with a required AssignmentExpression then the complexity of doing alternative #2 is about the same as for alternative #3 Allen On Nov 10, 2013, at 11:04 AM, Sam Tobin-Hochstadt wrote: On Sun, Nov 10, 2013 at 1:46 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: 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. It would be possible to just parenthesize the YieldExpression if you actually wanted one in an extends clause, right? Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
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:al...@wirfs-brock.com
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
Brendan Eich wrote:
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
Sorry, higher-precedence (jetlag)
nonterminal that does not end in AssignmentExpression, namely
LogicalORExpression?
Another way to go is far higher precedence, say LeftHandSideExpression?
That avoids all arithmetic operators, unary and binary.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
On Sun, Nov 10, 2013 at 5:26 PM, Brendan Eich bren...@mozilla.com wrote:
Brendan Eich wrote:
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
Sorry, higher-precedence (jetlag)
nonterminal that does not end in AssignmentExpression, namely
LogicalORExpression?
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.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
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? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
I have heard it argued that await needs higher precedence than we've been considering for yield, but I don't remember the argument. Anyone? Would LeftHandSideExpression be adequate for whatever that argument was? In the future of promises, we will either continue to use yield as await, or we will provide an (essentially synonymous) await. Either way, it would be good for both of these to have the same precedence, and for that precedence to satisfy both needs. On Sun, Nov 10, 2013 at 5:45 PM, Brendan Eich bren...@mozilla.com 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? /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: optional yield expression creates ambiguity
I believe the argument is that you'd want `await a + b` to be `(await a) + b`, whereas with `yield` it's `yield (a + b)`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
So would LeftHandSideExpression satisfy both needs? I note that this also raises the issue of the precedence of the yield and await expressions themselves. This would argue that the yield expression itself be high precedence. This would not be a decision we could relax later. On Sun, Nov 10, 2013 at 6:15 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I believe the argument is that you'd want `await a + b` to be `(await a) + b`, whereas with `yield` it's `yield (a + b)`. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
Domenic Denicola wrote: I believe the argument is that you'd want `await a + b` to be `(await a) + b`, whereas with `yield` it's `yield (a + b)`. We need a debugged grammar for await, when ready. We have one for yield (existence proofs in several browsers now), and I think we can fix ClassHeritage easily. The reason why yield is low-precedence, at AssignmentExpression level, is to make the observed common case of yield a + b meaning yield (a + b). Python follows the same design, but the design comes from use-case frequency, not directly Python authority. C# 5.0 (http://www.microsoft.com/en-us/download/dlx/thankyou.aspx?id=7029) makes await expression both a statement-expression (the entirety up to the ; terminator of a statement-expresion) and a unary-expression (which cannot be a statement-expression in C# -- but can in JS). If we are copying C#, we can use a lookahead restriction as usual to handle the statement-expression vs. unary-expression cases. We can thus make async a unary prefix operator. You may object: why have the two operators at such different precedence levels. It's a good question, but if we are going by precedent from two different languages, then the answer may be because Blub did it that way. Before we settle for that hash of a design, I'd like to know why C# put async at unary precedence. Maybe Luke knows, or can find out. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
Mark S. Miller wrote: So would LeftHandSideExpression satisfy both needs? Mark, LeftHandSideExpression is my proposal for the replacement of AssignmentExpression in ClassHeritage, *not* for anything to do with YieldExpression. I note that this also raises the issue of the precedence of the yield and await expressions themselves. This would argue that the yield expression itself be high precedence. This would not be a decision we could relax later. No, we already have lots of experience with yield, in JS as well as in Python. It's low precedence for good usability reasons (see last post). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
Ok, I withdraw the suggestion. LeftHandSideExpression in ClassHeritage seems good. +1. On Sun, Nov 10, 2013 at 6:34 PM, Brendan Eich bren...@mozilla.com wrote: Mark S. Miller wrote: So would LeftHandSideExpression satisfy both needs? Mark, LeftHandSideExpression is my proposal for the replacement of AssignmentExpression in ClassHeritage, *not* for anything to do with YieldExpression. I note that this also raises the issue of the precedence of the yield and await expressions themselves. This would argue that the yield expression itself be high precedence. This would not be a decision we could relax later. No, we already have lots of experience with yield, in JS as well as in Python. It's low precedence for good usability reasons (see last post). /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
Brendan Eich wrote: C# 5.0 (http://www.microsoft.com/en-us/download/dlx/thankyou.aspx?id=7029) makes await expression both a statement-expression (the entirety up to the ; terminator of a statement-expresion) s/statement-expresion/expression-statement/ on last line, blargh! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
