I'm maybe biased, but I would love to consider "yield" as a function.
Indeed, it calls another code, which can return you a value. That looks very
similar to a function call to me. If we do this, the predecence becomes
intuitive again:
var x = yield(a) + yield(b);
yield(a+b);
I think there was a proposal to allow parenthesis-free function call at some
point at the root of a statement. When it lands, you'll be able to do things
like
yield a+b;
as a normal statement again. In the mean time we can just use parentheses,
that's not a huge issue and it helps clarity.
But maybe this is too late to change ES6, it's just an idea I had while
reading this thread, not a strong call for change.
-----Message d'origine-----
From: Brendan Eich
Sent: Saturday, June 15, 2013 6:17 AM
To: Dean Tribble
Cc: Bruno Jouhier ; es-discuss@mozilla.org
Subject: Re: Precedence of yield operator
This is all on the agenda for ES7. It cleanly missed ES6 in May 2011(!).
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014748.html
/be
Dean Tribble wrote:
This is a familiar discussion from C#. I forwarded it to the mediator of
that convresation and got a nice summary, pasted here:
---------- Forwarded message ----------
From: *Mads Torgersen* <mads.torger...@microsoft.com
<mailto:mads.torger...@microsoft.com>>
Date: Fri, Jun 14, 2013 at 2:11 PM
Subject: RE: Precedence of yield operator
To: Dean Tribble <trib...@e-dean.com <mailto:trib...@e-dean.com>>
I’m not on the mailing list. Feel free to forward to it.
In C# we have separate keywords too, and indeed the precedence differs as
described below. For “yield return” (our yield) the lower precendence
falls out naturally since it engenders a statement, not an expression.
“await” is not a reserved keyword in C# either, but we managed to wedge it
in all the same. Just adding await as an operator would lead to all kinds
of ambiguity; e.g. “await (x)” could be a function call or an await
expression, and the statement “await x;” could be a variable declaration
or an await statement.
However, in C# “await” is only allowed inside methods marked “async”, and
since there weren’t any of those around before the feature was introduced,
it is not a breaking change. Inside non-async methods, therefore, “await”
continues to be just an identifier.
I don’t know if a similar thing is possible in EcmaScript. But I believe
that a low-precedence yield as a substitute for a high-precedence await is
problematic: you never want “yield a + yield b” to mean “yield (a + (yield
b))”: the things you await – Task, Promises, Futures, whatever you call
them – just don’t have operators defined on them, and it would be silly to
parse them as if they might and then give errors (at runtime in
EcmaScript, at compile time in e.g. TypeScript).
Mads
On Fri, Jun 14, 2013 at 11:07 AM, Brendan Eich <bren...@mozilla.com
<mailto:bren...@mozilla.com>> wrote:
Bruno Jouhier wrote:
While playing with my little async/await library, I noticed
that I was often forced to parenthesize yield expressions as
(yield exp) because of the low precedence of the yield
operator. Typical patterns are:
var foo = (yield a()) + (yield b()) + (yield c());
That's actually a hard case, IMHO -- and "hard cases make bad law".
Many programmers would rather have the extra parens for uncertain
cases (C's misplaced bitwise-logical and shift operators, vs.
equality/relational; anything novel such as yield).
But the real reason for yield being low precedence is to avoid
precedence inversion. Consider if yield could be high-precedence,
say a unary operator like delete:
let x = yield a + b;
Oops, many people would want that to be equivalent to
let x = yield (a + b);
but if yield is at delete's precence level, it's rather:
let x = (yield a) + b;
Which is the rare ("hard", from law school) case.
For commutative operators such as +, over-parenthesizing is better
again, because
let x = b + (yield a);
and
let x = (yield a) + b;
ignoring order of effects in shared mutable store, and ignoring
floating point non-determinism, are equivalent.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto: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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
