Also, see Peter Hallams part from NodeConf 2011 where he walks through how await works: http://youtu.be/ntDZa7ekFEA?t=17m2s
On Wed, Apr 24, 2013 at 10:18 AM, Erik Arvidsson <[email protected]>wrote: > On Tue, Apr 23, 2013 at 8:01 AM, Mark S. Miller <[email protected]>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 <[email protected]> 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 <[email protected]>wrote: >>> >>>> Le 23/04/2013 01:31, Tab Atkins Jr. a écrit : >>>> >>>> On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt < >>>>> [email protected]> 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 >>>> [email protected] >>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>>> >>> >>> >>> >>> -- >>> -kg >>> >> >> >> >> -- >> Cheers, >> --MarkM >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > erik > -- erik
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
