Mark S. Miller (2013-04-23T11:58:59.000Z)
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>
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>