Precedence of yield operator

Mark S. Miller erights at google.com
Sat Jun 15 07:45:41 PDT 2013


If we do provide such special syntax, then I suggest (a variant on some
else's suggestion -- I forget who) that "yield" is to "function* as "await"
is to "function!", amplifying the association of "!" with asynchrony.
Rather than say "async function" or whatever, we'd just say "function!".
Since "function!" would be new in ES7, there's no reason to reserve
anything in ES6 to prepare for this.



On Sat, Jun 15, 2013 at 2:40 AM, Bruno Jouhier <bjouhier at gmail.com> wrote:

> If this is on the agenda for ES7 maybe ES6 should at least reserve "await"
> as a keyword in function* scopes.
>
>
> 2013/6/15 François REMY <francois.remy.dev at outlook.com>
>
>> 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 at 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<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.Torgersen at microsoft.com <mailto:
>>> Mads.Torgersen@**microsoft.com <Mads.Torgersen at microsoft.com>>>
>>> Date: Fri, Jun 14, 2013 at 2:11 PM
>>> Subject: RE: Precedence of yield operator
>>> To: Dean Tribble <tribble at e-dean.com <mailto:tribble at 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 <brendan at mozilla.com<mailto:
>>> brendan at 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 at mozilla.org <mailto:es-discuss at mozilla.org**>
>>>     https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>>
>>>
>>>  ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130615/adaa59e6/attachment.html>


More information about the es-discuss mailing list