github at esdiscuss.org (2013-07-12T02:26:56.927Z)
Hi David, see my response to Andy. `await` is just `yield` within a
`Q.async(function*`. Both async-functions/`await` and generators/`yield` are
shallow. Thus neither create the hazards of co-routines.
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/>
>
--
Cheers,
--MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130423/d4baca19/attachment-0001.html>
Hi David, see my response to Andy. "await" is just "yield" within a "Q.async(function*". Both async-functions/await are generators/yield are shallow. Thus neither create the hazards of co-routines. 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/> > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130423/d4baca19/attachment-0001.html>