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 <bruan...@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 <sa...@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@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -- -kg
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
