Here are some extra notes on the papers I mentioned before, now that I've re-read them.
Gasbichler and Sperber: The implementation of delimited continuations in Racket CS is about as much like the metacontinuation approach discussed in the beginning as it's like the implementation described in the rest of the paper: * Creating a prompt pushes onto the metacontinuation, just like `*reset` in the paper. But the new current continuation in Racket CS is immediately truncated after `k` is captured. That avoids the space problem that the paper mentions. * Then again, with multiple prompts, the metacontinuation stack looks a lot like the continuation stack in the paper. Capturing a continuation copies as many metacontinuation frames as needed to reach the relevant prompt (i.e., for a specific prompt tag). Section 7.2 of the paper looks right, except that Racket CS terminates the continuation as soon as it is created by a prompt, not when the continuation is later captured. To truncate a continuation, Racket CS's implementation uses (#%$current-stack-link #%$null-continuation) to truncate the current continuation at the point where it's known to be just one frame. See below for some thoughts on extended Chez Scheme with the C operator, instead. There's room for a better representation of metacontinuations to avoid the copy operation on continuation capture. Some sort of tree structure may be the right idea. A better data structure would matter if there are prompts with enough different prompt tags in the current continuation. That doesn't often happen, but it could happen with enough uses of `call/ec`, because each escape continuation is implemented as a prompt with a fresh tag. Dybvig, Peyton Jones, and Sabry: Section 3.2 says that the metacontinuation approach tends toward +F+. I think it tends toward +F-; maybe it's a question of putting the prompt on one side or the other of a link in the metacontinuation chain, and section 3.3 resolve the issue by putting the prompt as its own element of the metacontinuation-style list. Meanwhile, the primitives exposed to Racket provide -F- (effectively) by including prompt handlers; that's implemented with a little trampoline on the outside of each prompt --- which, ok, is a little more complexity, but it works out naturally it you're going to have prompt handlers. The Racket CS implementation of delimited control is very much like the Scheme implementation in this paper. Racket's implementation just adds a more to deal with prompt handler, continuation marks, and winders. The paper's implementation sets up an `abort` continuation that expects a thunk, instead of explicitly truncating a continuation; explicitly truncating should be a little faster (because it avoids another closure creation, at least). Section 7.5, about the Haskell implementation, points out that the C operator is more useful here than `call/cc`. That avoids the need to set up an `abort` continuation, and it could replace an explicit truncation operation. Then again, `call/cc` is still handy for various purposes in Racket CS's Rumble layer to reflect on the continuation without aborting. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20191203190100.EBDAA65018B%40mail-svr1.cs.utah.edu.
