Continuation Explanation Rev Zero

EditHint: This is a copy of ContinuationExplanation before that page was "refactored" 2005-Sep-30. Some of the material here should not have been deleted (the Tennent quote is one of several examples).

Continuations are the conceptual equivalent of saved executable states, that can be restored and restarted, exactly like threads. Unlike threads, continuations can be restarted from the same point in time again and again. At each point in a program, there is an implied continuation that is whatever would happen next.

Continuations are sometimes explained as "goto with parameters". A much better explanation is that they are snapshots of threads at a particular moment in time, although they cannot be accessed from outside of their local process.

Continuations are best used to reenter the same code repeatedly.

"The continuation for some computation is whatever comes after it, expressed as a function of the result for that computation." -- R.D.Tennent, Principles of Programming Languages, 1981

Continuations are used in DenotationalSemantics to describe the semantics of control mechanisms and of control commands such as jumps.

See SpaghettiStack!

A continuation is roughly a context where program execution will continue. For example, with a statement like PRINT 1+2, the continuation when 1+2 is being evaluated can be thought of as a procedure that will take a number and print the result. Some languages like Scheme [SchemeLanguage] or SML [SmlLanguage] allow you to grab the current continuation as a first-class object (see CallWithCurrentContinuation).

IIRC it's just SML/NJ that allows you to use FirstClass reified continuations And IconLanguage.

Continuations are advantageous because they can turn procedural code into an event-driven StateMachine, even deeply nested procedural code. Whenever the code needs another event, it escapes via a continuation. When the event is available, the code is resumed where it left off. Without a continuation, you'd need a complicated state machine that saves its future computation using explicit state variables, so that when it's called again, it can figure out what to do next. You get a similar continuation-like effect in CooperativeThreading when you explicitly select another thread to run, and give it a way to run back to you. E.g. your event loop may be represented as a thread, and so you when you need another event, you yield to the event loop thread explicitly. When it has an event for you, it yields back to you. Continuations are more dynamic than cooperative threads because they are created on the fly, implicitly. They are not really a separate execution context with its own stack. Continuations are to cooperative threads what, err, LexicalClosures are to C++ function objects. ;)

[This is a total SWAG based only on what I've been able to gather on Wiki and from: http://www.tismer.com/research/stackless/spcpaper.htm#_Toc470444056 which I reached from StacklessPython. -- PhilGoodwin]

: A continuation is a pointer to an instruction within a stack frame. Holding this pointer keeps the frame from being garbage collected. This pointer can be used to return control to the stack frame. This works just like a function call, except that control jumps to the middle of the function instead of the beginning. When a function passes control to a continuation of another function, the function so called is a "coroutine".

(I now know this to be incomplete - some amount of state beyond the current stack frame is saved and some is left available for alterations that will be visible when the continuation is called, but I'm not entirely certain which is which. -- pg)

Phil, it might be easier if you rephrase this in terms of "environments", which may well be in a tree on the heap.

Also see ContinuationsAndCoroutines.

I don't think that you can just abstractly understand the concept of continuations. You should rather pick one of the LanguagesThatSupportContinuations? and implement some exercises that make use of CallWithCurrentContinuation. For example, it's possible to implement your own short-circuit boolean operators with continuations. When I tried to implement such operators in the SchemeLanguage on my own, I finally got it. -- PascalCostanza

"Applications of Continuations" by DanielFriedman is a tutorial paper on continuations, with exercises at the end.

Available at http://www.cs.indiana.edu/hyplan/dfried/appcont.pdf.

The paper "The Discoveries of Continuations" (1993) by John C. Reynolds gives a brief account of the early history of continuations, where basic concepts were independently discovered an extraordinary number of times (see http://citeseer.nj.nec.com/reynolds93discoveries.html).

Recommended if you already understand continuations: http://www.dcs.qmw.ac.uk/~peterl/danvy/.

A wonderful ContinuationExplanation for dummies is here: http://rubygarden.org/ruby?ContinuationExplanation.

Also see ContinuationPassingStyle, ContinuationPattern, ContinuationsInCee, and StacklessPython.

What is the source of the name "continuation"? Is it the paper ActorsAndContinuousFunctionals, or is there an earlier source?

What would be the downsides if continuations were made accessible from outside of a process? The upside is obvious, a complete merging of the concepts of threads and continuations. Are there any downsides?

CategoryLanguageFeature CategoryContinuation

Last edit by GrammarVandal.