ES6,ES7,ES8 and beyond. A Proposed Roadmap.

Mark S. Miller erights at
Tue Apr 23 04:56:56 PDT 2013

On Tue, Apr 23, 2013 at 12:12 AM, Andy Wingo <wingo at> wrote:

> On Tue 23 Apr 2013 01:31, "Tab Atkins Jr." <jackalmage at> writes:
> > On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt <samth at>
> 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 <> and the Q.async definition it uses
at <>.
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.

> Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list