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
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?
https://docs.racket-lang.org/guide/prompt.html
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.
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.
