Single frame continuations proposal

Kris Zyp kris at
Tue Apr 6 14:40:46 PDT 2010

Hash: SHA1

On 4/6/2010 3:13 PM, 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.

We definitely have not introduced shared-state concurrency, but if you
think choosing to simplifying normalization of sync/async is
potentially unhelpful, than certainly the alternate proposal based on
"yield" would be better since it pushes the branching of logic on
values to user land.

> 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(...) { f->(...); g->(...); }
> 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.

With normal continuation passing style if the exception takes place in
the next event turn (for g's event handler), g's event handler would
call the callback in foo, resulting in an inverted stack. Does that
makes sense?

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

In addressing your other issues, like I said to Waldemar, would it be
reasonable to start with a definition and sample translation of JS1.7
generators (since I believe we all understand those) and then look at
possible incremental changes to make it more broadly useful? Then
maybe my poorly written code wouldn't get in the way :/.

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