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

Erik Arvidsson erik.arvidsson at
Wed Apr 24 07:53:50 PDT 2013

Also, see Peter Hallams part from NodeConf 2011 where he walks through how
await works:

On Wed, Apr 24, 2013 at 10:18 AM, Erik Arvidsson
<erik.arvidsson at>wrote:

> On Tue, Apr 23, 2013 at 8:01 AM, Mark S. Miller <erights at>wrote:
>> Hi Kevin, you are correct that it isn't a co-routine, and that it
>> corresponds to a mechanical CPS rewrite of only the local function itself.
>> Fortunately, it is *exactly* the same CPS rewrite required to account for
>> the semantics of generators/yield as a mechanical transform. This is in
>> fact how Traceur implements generators.
> And how we implement 'await' too.
> For Traceur both GeneratorTransformer and AsyncTransformer extends
> CPSTransformer which does the heavy work of building the state machine.
> We proposed await at Redmond 2011 and showed our implementations at
> JsConf2011
>> On Tue, Apr 23, 2013 at 3:45 AM, Kevin Gadd <kevin.gadd at> wrote:
>>> My information may be incomplete (I haven't used await since the beta of
>>> the release that introduced it), but 'await' is part of the function's
>>> return type/signature in C#; that is, a function that may await has a
>>> different signature than a function that may not.
>>> Calling a function that may await during its execution returns a value
>>> that must be 'awaited' so things propagate out nicely and there are no
>>> surprises.
>>> Furthermore, at least when discussing the C# version of the 'await'
>>> concept, it does *NOT* suspend execution of anything. It is NOT a
>>> coroutine. It is a callback-passing transform, wherein a function that uses
>>> await is mechanically transformed by the compiler into a series of
>>> callbacks and the compiler mechanically ensures that the callbacks are
>>> passed into the .NET equivalent of promises (Task<T>) in order to resume
>>> execution at the appropriate time.
>>> If the intent is to model a proposed ES 'await' on another language, my
>>> apologies: the only major implementation using this keyword that I know of
>>> is C#. If the intent is to be inspired in any degree by C#'s it's worth
>>> reading up on it and checking out some of the examples; I'd especially
>>> encourage you to look at the output of the compiler transform. It's less
>>> complex than one might think and the biggest complication (in my opinion)
>>> is how it influences lifetime management.
>>> One way to look at it is that await and yield are sort of inverses:
>>> yield mechanically transforms a function into a state machine that is
>>> driven from the outside by someone advancing an enumerator, while await
>>> mechanically transforms a function into a state machine that is driven
>>> 'internally' by the function chaining the continuation of its execution to
>>> the result of some future that it implicitly owns (or has been passed
>>> ownership of).
>>> In the C# model, 'await' can be used on any value that is 'awaitable',
>>> which is (based on my last discussion with the designer of the keyword)
>>> defined simply as the object having a 'GetAwaiter' method, which returns an
>>> object you can use to chain a callback to the fulfillment of the value. To
>>> me this is essentially a narrowly defined interface that represents the
>>> 'then'/'OnComplete'/'registerCallback' portion of the typical
>>> Future/Promise consumer interface.
>>> Part of the importance of await as a mechanism is that it removes the
>>> need for an external driver, like the task scheduler implied by systems
>>> like task.js and my own task scheduler. It also integrates much more simply
>>> into callback-oriented async models than an approach based on yield and
>>> task schedulers does. The clarity of the definition of 'await' is also
>>> valuable in this regard, as there is no difference between an enumerator
>>> being used as a coroutine and an enumerator being used as an enumerator as
>>> far as their types go - you can't just look at the definition or body of
>>> the function and immediately know, 'ah, this is a coroutine'. You have to
>>> infer that based on how it is used and what kind of values it yields.
>>> If you have more precise questions about the concept and how it works, I
>>> can try and dig up the archived conversation I had with the keyword's
>>> designers and see if there are any relevant quotes to share here, or
>>> perhaps even ask them to try and answer any questions you have that I can't.
>>> As a final note, it is definitely the case that 'await' was fully
>>> expressible mechanically in previous versions of C#. It follows the C#
>>> tradition of replacing common idioms and patterns with compiler-generated
>>> versions of those patterns that are easier to write and more robust against
>>> mistakes; things like error propagation and lifetime management in
>>> particular are greatly simplified by the compiler's aid. I think this is
>>> consistent with the approach TC39 is taking with things like the module
>>> system so considering a similar feature is at least a good match. I don't
>>> have a strong opinion as to whether JavaScript needs 'await', beyond that
>>> the traditional callback-passing style of JS async programming is a
>>> complete nightmare.
>>> On Tue, Apr 23, 2013 at 1:26 AM, David Bruant <bruant.d at>wrote:
>>>> Le 23/04/2013 01:31, Tab Atkins Jr. a écrit :
>>>>  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.
>>>> Your description reminds me of coroutines and Dave Herman's article
>>>> about it [1].
>>>> Is await immune from the issues described as:
>>>> "Once you add coroutines, you never know when someone might call yield
>>>> [considered as a stack pause primitive]. Any function you call has the
>>>> right to pause and resume you whenever they want, even after any number of
>>>> spins of the event loop. Now any time you find yourself modifying state,
>>>> you start worrying that calling a function might interrupt some code you
>>>> intended to be transactional. "
>>>> Overall, control-flow related syntax cannot give you authority that
>>>> goes beyond your own frame. If that happens, then any library (think
>>>> Node.js modules which are recursively by hundreds in any decent-sized
>>>> project, so you don't have to to review them all) can start pretend being
>>>> smart and mess with you invariants if you expected the library function to
>>>> return (and that's a very natural thing to expect).
>>>> David
>>>> [1]**2011/12/14/why-coroutines-**
>>>> wont-work-on-the-web/<>
>>>> ______________________________**_________________
>>>> es-discuss mailing list
>>>> es-discuss at
>>> --
>>> -kg
>> --
>>     Cheers,
>>     --MarkM
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> --
> erik

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

More information about the es-discuss mailing list