Single frame continuations proposal

Dave Herman dherman at
Tue Apr 6 15:04:35 PDT 2010

> > Greasing the wheels of shared-state concurrency is dangerous and
> > not a good idea for ES.
> We definitely have not introduced shared-state concurrency

Introduced, no-- it's already there. IMO what this does is make it too easy to trip over. You're talking about a use case where clients can be oblivious to whether something is concurrent or not. I do not ever want to encourage web programmers to be oblivious to whether array mutations are synchronous.

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

You do realize compilers aren't going to implement this with CPS, right? They'd likely reify the activation frame as an internal data structure (probably in C++, the poor dears), which they probably already have implemented anyway. CPS is just one (poorly performing) implementation strategy for first-class continuations. This is an implementation concern, not something we need to address in the semantics.

Whatever implementation tricks NarrativeJS had to go through were based on the fact that Neil didn't want to implement a JS engine, so he just did a CPS translation. That's not the case for us.

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

Earlier in this thread, I demonstrated a simple single-frame semantics and shown how generators could pretty easily be layered on top of it (not the most important design criterion, but a good sanity check). Actually, I started digging into SpiderMonkey this weekend and it doesn't look too prohibitively hard to implement. Yeah yeah, famous last words. We'll see. :)

One thing I'd like to do is write up a wiki page with a brief explanation of the design space. I can't afford to spend much time on it but we could churn forever stabbing at proposals if we aren't a little more systematic. But honestly, IMO, this isn't nearly as high a priority as some of the other features and proposals on the table. So I may need to put it on the back burner.


More information about the es-discuss mailing list