Documentation feedback : Continuations

Good afternoon,

There are a couple points I found difficult to follow in the Racket documentation about continuations; the difficulty is not about understanding continuations (even though that also is the case), but mainly about following the documentation.

This is all coming from my beginner perspective to Racket in general.
I feel like posting a github issue for documentation is too formal and overkill, so I hope you don't mind me posting here :slight_smile:
If there is a better place, do let me know!

#1 Confusion

source: 10.4 Continuations
confusion from quote : Applies proc to the given args with the current continuation extended by a prompt.
question: What is a prompt or continuation prompt?
remark : this other documentation does not define what a prompt is : 10.4 Continuations

#2 Confusion

source: 10.4 Continuations
confusion from quote : Returns a constant prompt tag for which a prompt is installed at the start of every thread’s continuation;
question: What is a prompt tag or continuation tag ?
remark : is there a link to a beginner friendly resource explaining this concept?

#3 Resources on continuation memory usage?

Beyond explaining the API for continuations, I have a question about the memory usage of continuations, and how long the state is stored in memory.
The usual example is a webserver which uses continuations. If this server has many users at once, how do continuations work? Are their state held in memory, or is this state serialized somewhere then retrived?

Is there a resource about this? Did I miss something in the docs?


Thank you!

Here is some explanation of prompts from the Guide that can help clarify the first two questions. Basically, prompts let you delimit the continuations so continuation-capturing operations can stop at some point in the middle of the stack frames without going all the way until the end. Then, each prompt is associated with a tag that can be used to distinguish prompts installed by different applications.

I'd say in general it is more convenient to understand a concept from the Guide, rather than directly reading the Reference. Optionally, the citation Flatt07 gives a more formal account of continuation prompts (e.g. the % frame in Sec 3.1) and how they relate to the various operators developed in the literature. The paper A Monadic Framework for Delimited Continuations also gives an extensive introduction to continuations & prompt-delimited continuations, although it is intended for researchers or people familiar with Haskell.

Well, prompt is from this in the Guide or the function that installs a prompt frame call-with-continuation-prompt. The operator you linked to is a particular operator for installing prompts.

Here are some prompt tag functions: make-continuation-prompt-tag, default-continuation-prompt-tag and continuation-prompt-tag?. For each prompt, you can associate it with a tag that acts like the "name" of prompts. Then, you can delimit continuations only by prompts associated with a specific tag -- essentially allows different applications to delimit continuations in their own manner without being interfered by the prompts installed by other applications. This like the treatment of named prompts in A Monadic Framework for Delimited Continuations


Some additional uses of @tech in the Reference would probably not go amiss here

For rather practical pre-Racket papers on delimited continuations with prompt hierarchies, check out


2 papers by Dorai Sitaram whose dissertation is on the university of control delimiters.


Did I miss something in the docs?

Note the hand at the top of the page for 10.4 at the right hand side.

The section in the guide is meant to introduce the concepts.
In this instance prompts are explained.

What I'd love to see is an explanation in plain English of the notation used in describing the "reduction rules" of shift/reset and prompt/control and the other delimited continuation operator pairs.

control turns the pending computation (in many languages, implemented as a stack/environment) between its current “location” and the closest prompt (in many languages, a marker on the stack) into a function and hands it to the handler associated with the prompt together with the value that was supplied to control in the first place.

shift goes to the closest reset but does not create a function from the stack but a control-delimited procedure. That is, it inserts a reset (to which it connected) into the “bottom” of the function so that any future control operation in this function is bounded by the same delimiter.

(That’s as plain as I can make it after inventing control delimiters in pretty much three decades ago and thinking about them/talking with others about them ever since. And because English is my second language I called them “prompt” and all fellow grad students laughed at the chosen noun.)

This Stackoverflow Q&A is the closest I've come to seeing the notation explained (And the best for the difference between the two pairs), but it's still not very clear. What does E[control k expr] read as? What's E? What do the square brackets represent? What does where E has no prompt mean?

I know what they do, and have successfully used them as alternatives to call/prompt , abort/cc etc. in code; I just don't know how to interpret the rules describing them.

E represents the dynamic context of an expression --- the computations to be done in the future -- with an expression that contains a hole.
-- Example If the expression is (+ 1 (+ 2 3)), the context of (+ 2 3) is (+ 1 [ ... ]) where [...] is he hole.

E[e] represents the result of filling the context E with the expression e.
-- Example if E is (prompt (+ 1 [ ... ])), then E[(control identity)] is (prompt (+ 1 (control identity))))

So when you see (prompt E[(control f)]) and there is a (possibly implied side condition) that E is free of any other prompts and f a function, you see a (small) program that is about to grab the continuation.

A reduction rule written e1 --> e2 is just like an equation: it's a pair of two expressions and we say it is related by the (strangely named relation --> instead of = which is what you often see in school/college math). With contexts, the left-hand side describes the state of a program expression before the next instruction is "executed". The separation between context and the expression inside helps recognize what this next "instruction" is. The right hand side describes the state of the program after the expression is executed.