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

Mark S. Miller erights at google.com
Tue Apr 23 05:01:53 PDT 2013


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.


On Tue, Apr 23, 2013 at 3:45 AM, Kevin Gadd <kevin.gadd at gmail.com> 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.
> http://msdn.microsoft.com/en-us/library/vstudio/hh156528.aspx
>
> 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 gmail.com> 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 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.
>>>
>> 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] http://calculist.org/blog/**2011/12/14/why-coroutines-**
>> wont-work-on-the-web/<http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/>
>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
>
> --
> -kg
>



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


More information about the es-discuss mailing list