natively negotiating sync vs. async...without callbacks

Kris Zyp kris at
Thu Dec 9 08:28:10 PST 2010

Hash: SHA1
The generators from JS 1.7 are too specific to provide much help with
promises, IMO. Adding a yield operator fundamentally alters the
semantics of the entire surrounding function, violating the principle
of locality. Consequently you need special mechanisms (like Neil's
library) to even call an async function, and you can't "return" values
either (with the return operator). Solving these problems was the
point behind the shallow continuation proposal that we worked on. Does
the generator strawman build on that work, or does it still fail to
preserve locality?

My understanding of Kyle's proposal was that he did not want to
introduce real continuations, but this was more of a syntax for a
specialized callback chain, reducing the verbosity of anon functions,
callback registration. I'd prefer more of a generalized solution for
reducing the size of anon functions (which has been discussed to great
lengths here in the lambda threads). However, my belief on async is
that the verbosity is only part of the pain, working with async within
various control flows (loops, branches, etc) is more of a burden,
hence the need for continuations (shallow/single frame, of course).

On 12/9/2010 8:55 AM, David Herman wrote:
> I pretty much abandoned that line of investigation with the
> conclusion that generators:
> are a good (and well-tested, in Python and SpiderMonkey) design for
> single-frame continuations. They hang together well; in particular,
> they don't have the issues with `finally' that some of the
> alternatives I talked about do. Moreover, the continuation-capture
> mechanisms based on call/cc or shift/reset require additional power
> in the VM to essentially tail-call their argument expression. When I
> tried prototyping this in SpiderMonkey, I found this to be one of
> the biggest challenges -- and that was just in the straight-up
> interpreter, not in the tracing JIT or method JIT.
> Generators work well for lightweight concurrency. As a proof of
> concept, I put together a little library of "tasks" based on generators:
> Somebody reminded me that Neil Mix had written a very similar
> library several years ago, called Thread.js:
> and there's another library called Er.js that built off of that to
> create some Erlang-like abstractions:
> Dave
> On Dec 8, 2010, at 11:36 PM, Tom Van Cutsem wrote:
>> The spirit of the proposal is that this special type of
>> statement be a linear sequence of function executions (as
>> opposed to nested function-reference callbacks delegating
>> execution to other code).
>> The special behavior is that in between each part/expression of
>> the statement, evaluation of the statement itself (NOT the rest
>> of the program) may be "suspended" until the previous
>> part/expression is fulfilled. This would conceptually be like a
>> yield/continuation localized to ONLY the statement in question,
>> not affecting the linear execution of the rest of the program.
>> This reminds me of a proposal by Kris Zyp a couple of months ago
>> ("single frame continuations")
>> I don't think that discussion lead to a clear outcome, but it's
>> definitely related, both in terms of goals as well as in mechanism.
>> I also recall it prompted Dave Herman to sketch the design space of
>> (single-frame) continuations for JS:
>> Cheers,
>> Tom
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at <mailto:es-discuss at>
> _______________________________________________
> es-discuss mailing list
> es-discuss at

- -- 
Kris Zyp
(503) 806-1841
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list