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 <[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
