Continuation Explanation

A clearly written and easily understandable explanation of Continuations can be found on Wikipedia at http://en.wikipedia.org/wiki/Continuation.

This page was changed on 2005-Sep-30. The previous version of this page has been temporarily archived to ContinuationExplanationRevZero.

Continuations are not identical to any other control construct at all. But they are most like threads in that an implementation of one can be used to implement the other.

"continuation" is a more precisely defined term than "thread" and so some thread implementation are not as powerful as continuations. Pthreads, for instance cannot be used to implement some control structures that could be implemented with a continuation.

It can be said that a continuation is goto with a parameter that is the value of the computation that transferred the control. It is unlike a function call because, while it is possible to return to the original computation it is not necessarily expected.

An ideal way to handle tail recursion for Scheme is to make everything use ContinuationPassingStyle behind the scenes.

Continuations are snapshots of threads.

Continuations are inactive multiply-resumable threads. So unlike normal threads, resuming a continuation doesn't use up its power to execute that particular piece of code.

Facts about continuations

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

Depending on the implementation, typically "continuations over threads", it may not be possible to call a continuation from outside of the process where it's defined. This is a limitation of the implementation and not of the concept.

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. (Trivial to do in OriginalIoLanguage. -- Walt RorieBaety?)

Issues

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?

In what way, if any, are continuations different from threads which are automatically forked when called? If there isn't any difference then threads are continuations and continuations are threads. There is a symmetry between them that is hidden by some ugly implementation details. For example: you typically can't arbitrarily unwind the stack of a thread but you can a continuation; conversely, you can't call a continuation from outside its process like you can with a thread.

CallWithCurrentContinuation in thread form is this:

fork current thread
send message to daughter thread, passing self
block self

Some References

refactored 6/8/2006, removed ThreadMode and non-continuation content, PhilGoodwin

CategoryLanguageFeature CategoryContinuation CategoryFunctionalProgramming