Abstractly, a continuation is a representation of the state of an execution, and
especially its "execution stack" 
[http://en.wikipedia.org/wiki/Continuation].

There's a delightful article explaining continuations at [http://www.intertwingly.net/blog/2005/04/13/Continuations-for-Curmudgeons].

''[DKF] 17-Apr-2005:'' Interesting. I just wish it was easy to apply in Tcl, but our openness to extension, especially by C libraries, makes this very tricky indeed.

''[WHD] 17-Apr-2005:'' Damn.  I want this.  The idea of User Interface Continuations makes me drool.

''[jcw] - Yeah, me too, same reaction.
DKF, yes the C stack can cause trouble, but only when C calls back into Tcl.  There are probably many cases when this need not be a show stopper.
I think there are ways to get there.  Might be something to discuss at the tcl2005e conf - are you going to be there?''

''[NEM] 18-Apr-2005:'' You could sort of get this to work, if we went a similar route to Stackless Python (from what little I know of that project). You'd have to change all the C-API so that instead of re-calling into the interpreter with Tcl_Eval* APIs, they instead return a TCL_CALL or similar code with some code of where to go next in the interpreter result (i.e. trampoline). This is very similar to the recent proposals for tail-call optimisation (which is also very connected to continuations, through continuation-passing style, CPS). Obviously, it'd be an enormous amount of work to restructure the core and many many C extensions to do things this way. Continuations rock. (I should be at tcl2005e, and would love to discuss these ideas with people).

----
[Category Concept]