ES6,ES7,ES8 and beyond. A Proposed Roadmap.
Tab Atkins Jr.
jackalmage at gmail.com
Tue Apr 23 10:53:56 PDT 2013
On Tue, Apr 23, 2013 at 4:56 AM, Mark S. Miller <erights at google.com> wrote:
> On Tue, Apr 23, 2013 at 12:12 AM, Andy Wingo <wingo at igalia.com> wrote:
>> On Tue 23 Apr 2013 01:31, "Tab Atkins Jr." <jackalmage at gmail.com> writes:
>> > On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
>> > wrote:
>> >> What exactly would be the semantic difference between this and just
>> >> using
>> >> 'yield'?
>> > The semantic difference is that 'yield' pauses your execution and
>> > gives control to the calling code, while 'await' pauses your execution
>> > and gives control to the promise. Completely different direction of
>> > control-passing.
>> It seems quite unlikely that modern JS implementations would implement
>> `await' as you describe it. It's relatively easy to suspend computation
>> in one function frame, which is why we can have nice things like yield.
>> Suspending multiple function activations is done in some language
>> environments, but it would be difficult to retrofit into JS
>> implementations, which is why we can't have nice things like await.
> Hi Andy, look again at Domenic's gist at
> <https://gist.github.com/domenic/5428522> and the Q.async definition it uses
> I think the only proposed difference between "await" and "yield" is the
> name. The notion is that, when using ES6 generators and yield to get the
> effect associated with "await" in C#, he'd rather use the term "await" at
> the same time he's rather say "function^ ...." rather than
> "Q.async(function* ....". Other than these two simple local desugarings,
> "yield" and "await" are synonyms.
> The only issue at stake is whether the each bit of sugar is worth the cost.
> Fortunately, we'll gain experience with Domenic's middle pattern in ES6. In
> fact, we can start gaining experience with it today using Kris Kowal's Q on
> FF generators, which already work on ES5 on FF. Armed with this experience,
> we can then make an informed decision.
>> My 2c.
> FWIW, my 2c agrees with Sam on "await" vs "yield". If async functions are
> not common, then adding sugar for a small benefit isn't worth it. If async
> functions are common, then "yield" will come to be understood in the more
> general way that accounts both for their use in generators and their use in
> async functions. I doubt the "await" renaming is of adequate benefit to
> either scenario. People coming from C# can learn to say "yield" where they
> were used to saying "await".
> On something like "function^ ...." vs "Q.async(function* ...." I am more
> undecided. If async functions are common enough, I can see this additional
> bit of sugar possibly being worth it. It would be like the difference
> between "function" and arrow functions all over again. But we lived with
> "function" functions for a long time without too much pain. Even if async
> functions become common, I am skeptical this additional sugaring is urgent.
> Let's give our experience of these more time to cook.
I don't think yield and await are similar at all. You need to
interpose a control inverter between yourself and the outside world to
have them work similarly. They just both represent "freeze me, and
start me back up when something else happens", but that doesn't make
them identical, just related.
Further, overloading 'yield' means we can't produce an async
generator, which seems useful in itself. Domenic produced a silly
trivial example, but it's easy to imagine the usefulness of this in
non-trivial cases: for example, a generator that uses an XHR to
generate each value. This would produce a generator which yielded a
future each time it was called.
(This also seems to be almost precisely the semantics I was shooting
for with my "single-listener, non-lossy" event stream concept, which
More information about the es-discuss