It's a good explanation. I guess my question is deeper: what's the semantic case for having these things in the language? So far as I can see, these are purely optimization vs. a standard continuation. They allow the interpreter to "skip" the stuff on the stack above the reset, and thus free it earlier than it otherwise might. Otherwise the closure of the continuation code would need to save the reference to the whole stack, and everything it references.
So... why make the programmer do this? Can't you figure out for yourself the scope of the "highest free variable" in the referenced code?
the delimitation is not for data (that is closed over like any normal closure), it's for control.
when you apply a reified delimited continuation as a function it returns a value to that call site, to do the same with a traditional continuation you need to apply the reified continuation using call-cc, and it needs to know what to do with this continuation.
Comments
It's a good explanation. I guess my question is deeper: what's the semantic case for having these things in the language? So far as I can see, these are purely optimization vs. a standard continuation. They allow the interpreter to "skip" the stuff on the stack above the reset, and thus free it earlier than it otherwise might. Otherwise the closure of the continuation code would need to save the reference to the whole stack, and everything it references.
So... why make the programmer do this? Can't you figure out for yourself the scope of the "highest free variable" in the referenced code?
the delimitation is not for data (that is closed over like any normal closure), it's for control.
when you apply a reified delimited continuation as a function it returns a value to that call site, to do the same with a traditional continuation you need to apply the reified continuation using call-cc, and it needs to know what to do with this continuation.
http://www.cs.rutgers.edu/~ccshan/recur/recur.pdf