Single frame continuations proposal

David Herman dherman at
Tue Apr 6 14:13:57 PDT 2010

We've given this quite a bit of time, and I don't know how far we're going to get in understanding all the details of your proposal. But I think I can address some of my disagreements.

1) I'm skeptical whether the requirement you stated of future-proofing code for async implementations is likely to happen, and in fact, I think it would be harmful. Take your example: someone writes an Arrayish API, and maybe it's concurrent, maybe it's not, maybe it changes to become concurrent at some point. So a client writes:

    function push3() {

Whoever uses push3 now has to be aware that it may or may not happen concurrently, so they have to be concurrency-safe too. Otherwise they might be tempted to do:

    var x = arrayish.pop(); // this is gonna be 3, I'm sure of it!

and sadness would ensue. You're proposing making it easier to create mutable concurrent (or possibly-concurrent) data structures. Greasing the wheels of shared-state concurrency is dangerous and not a good idea for ES.

2) I don't fully understand why you have so much machinery around chaining continuations. There are two ways in which chaining happens in existing code: nested flows through host-API callbacks (expressed in CPS), and explicit composition. With first-class continuations, the former is already alleviated for free-- there's no need for additional machinery to wire together pieces of the continuation. And if you represent captured continuations as functions, you still get composition on the cheap with good old function composition.

3) I'm also unsure what you mean by "preserving causality" or "preserving stacks" -- but I thought you meant that you wanted debugging environments to be able to present natural stack traces in the presence of continuations. Again, this seems unproblematic to me with a traditional continuation-capture mechanism. Assuming a semantics where -> causes a continuation capture, if you do:

    function foo(...) {

and the call to g throws an exception, it's perfectly easy for an implementation to report that this came from the body of foo.

4) Your design seems to have too much window-dressing and I don't have confidence that it's well-specified in the core parts. At least, the goto-laden spec with implicit entry points won't cut it. I think it's fair to say, if Waldemar can't understand your semantics, You're Doing It Wrong. ;)

5) We should also aim for a design that tries to be compatible with existing API's, so that people don't have to write wrappers for all the standard libraries. As much as possible, anyway.


On Apr 6, 2010, at 6:04 AM, Kris Zyp wrote:

> Hash: SHA1
> On 4/5/2010 7:05 PM, Waldemar Horwat wrote:
>> David Herman wrote:
>>> Your answers keep leaving out the definition of the function
>>> that you're calling via `->', which is supposed to be the part
>>> that creates the requisite object with `continueWith' etc.
>>> Examples don't do much good if they skip the part they were
>>> supposed to illustrate!
>> I have the same comments as David here.  I don't understand what
>> you're trying to do here with the many levels of closures that
>> take closures that take closures that take closures that ... ad
>> infinitum.  I have yet to see the case that bottoms the whole
>> thing out.  The thing that makes your proposals so painful to read
>> is that the examples quickly blow up into too much code to figure
>> out your intent.
> That is kind of the point, continuation passing style quickly becomes
> extremely complicated for non-trivial code flows. However, if my
> coding examples are poorly organized or unnecessarily complicated, I'd
> be glad to change them. Maybe it would help if you translated some
> JS1.7 code (I assume you know how JS1.7 generators work), and I could
> use that as a basis for my samples. How about:
> function foo(){
>  var a = bar();
>  if(yield a)
>    yield hi();
>  bye();
> }
> Once again my primary intention is that JS1.7 generators provide the
> type of continuations/coroutines support that we want, they just need
> a more generalizable API, so they can be used for more than just
> generators.
> - -- 
> Kris Zyp
> SitePen
> (503) 806-1841
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla -
> FIcAnjeF5dyWRSzpuMIbiAnlM/nweGg2
> =nplm

More information about the es-discuss mailing list