Discuss
  • thinking about continuations

thinking about continuations

# David Herman (15 years ago)

Hey all,

I went ahead and wrote a series of blog posts this morning about the way I look at the design space for single-frame continuations for Harmony. I offer it as food for thought wrt how to approach the design. Obviously this is my personal angle, but it also covers a reasonably broad spectrum of prior work in the research world.

Delimited continuations? In ECMAScript?
http://calculist.blogspot.com/2010/04/delimited-continuations-in-ecmascript.html

The design space of continuations
http://calculist.blogspot.com/2010/04/design-space-of-continuations.html

Thinking about continuations
http://calculist.blogspot.com/2010/04/thinking-about-continuations.html

Harmony first-class activations
http://calculist.blogspot.com/2010/04/harmony-first-class-activations.html

,

# Waldemar Horwat (15 years ago)

David Herman wrote:

Thinking about continuations
http://calculist.blogspot.com/2010/04/thinking-about-continuations.html

Your attempted fix for evaluating finally blocks just moved the problem elsewhere. Since in the final expression you have A(... A(x)), you'll just end up executing the same finally block twice under certain circumstances.

Waldemar
# David Herman (15 years ago)

Yes, that's an excellent point-- something like:

function captured() {
    try {
        handler->();
        throw "throw";
    }
    finally {
        alert("finally!");
    }
}

function handler(k) {
    k();
}

This calls the handler with A still on the stack, and the handler runs A again; then throwing passes through the finally twice, resulting in two alerts.

Thanks for the careful reading. Now I'm not sure whether the function call notation makes sense. There's a pigeonhole problem with finally: if you expect a capturing form of function call to happen in the context of its handlers/finalizers, but you also expect the handlers/finalizers to be executed when the activation is suspended, then you can't guarantee that a finally block only executes once.

With generators, this doesn't come up because `yield' simply jumps immediately out of the frame, without invoking additional user code first.