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

Erik Arvidsson erik.arvidsson at gmail.com
Wed Apr 24 07:18:11 PDT 2013


On Tue, Apr 23, 2013 at 8:01 AM, Mark S. Miller <erights at google.com> 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. http://goo.gl/QKXO0

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 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130424/841f9320/attachment-0001.html>


More information about the es-discuss mailing list