Single frame continuations proposal

Waldemar Horwat waldemar at google.com
Tue Apr 6 14:37:45 PDT 2010


David Herman wrote:
> 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() {
>         arrayish.push->(3);
>     }
> 
> 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:
> 
>     push3();
>     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.

Yes, a good example of how this proposal doesn't compose.  Suppose push3 returned an object which the caller needed:

    ...
    function push3() {
        arrayish.push->(3);
        return someComputation();
    }

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

How would you get something like this to work?

> 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.

Ditto.

> 3) I'm also unsure what you mean by "preserving causality" or "preserving stacks"

Me too.

> 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.

Yes, that bothers me too.  I'd want a simple continuation, not a continuation that takes a continuation parameter.


6.  If I understand it correctly, another issue I see is that this transformation causes an exponential code size blowup in situations like the following:

while (condition0) {
  if (condition1) x = a->(x);
  if (condition2) x = a->(x);
  if (condition3) x = a->(x);
  if (condition4) x = a->(x);
  if (condition5) x = a->(x);
  if (condition6) x = a->(x);
  ...
}

    Waldemar


More information about the es-discuss mailing list