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).

''The core is not that far from doing it.  At one point I had an experimental patch working, which copied the C stack away and back.  Not sure it covered all the cases, but it was definitely very close to full contins across all of Tcl and C. -[jcw]''

''[WHD]:'' I don't see why the C stack is an issue, based on what the article says.  A closure consists of a stack frame and its parent stack frame, and so on recursively, it says; but a continuation, so far as I can tell, is a single stack frame.  Suppose we made the rule that you could "yield" only from the body of a normal proc....  '''Oh.'''  If you do it from within a while loop, say, you've got the C stack involved.  '''Never mind.'''  (Or is there something else I'm missing?)

''Will, the stack becomes a tree, because processing (and further nesting) can proceed at any continuation point.  Yes, C loops and C re-entering Tcl (as foreach and proc do now when evaluating their bodies) is where things get tricky. -[jcw]''

'''[RHS]''' ''17Apr2005'' One of the most interesting (and informative) descriptions I've seen of the use of continuations was in the area of web programming. The programmers used them to use web pages as if they were stateful. The "process" that the web pages are involved with work linearly. Each time it needs input from the user it saves its current continuation (which contains everything about where it is in the process) in a hashtable. It then returns a web page with a form to the user, and one of the elements of the form (a hidden one, I presume) contains the key into the hash table for the current continuation. Once the user fills in the form and hits submit, the process can look up the continuation in the hash table and continue right where it left off... Only, now, it has the data it needs to continue, as provided by the form.

'''JR''' ''18Apr2005'' What I think would be a nifty use for continuations would be to unnest [vwait].  As everyone knows, if you call [vwait] from inside an event handler then the outer [vwait] cannot return until the inner one does.  This gets messy when things that you may not expect call [vwait] internally, with the general conclusion of '''vwait considered harmful'''.  However, it is also very useful in some circumstances which makes this all a pain.  If we had continuations, then vwait could simply be reimplemented as something like

   proc vwait {var} {
      uplevel trace variable $var w [info continuation 1]
      return -code return
   }

Where '''info continuation''' ''level'' returns a command that executes the continuation.  Then make the stack frames into Tcl_Objs and increment the reference counts to keep them around and it all works naturally.  ''(if only it were that simple)''

'''[SS]''' ''18Apr2005''' Using setcontext and getcontext calls that are POSIX and AFAIK also available in some form on every platform Tcl supports allows for
continuations without a stackless interpreter (basically you save the C stack too). This is how it's in plan to implement continuations into [Jim].
(this is also how [Ruby] implements continuations IIRC).

[jcw] - SC/GC work by switching stacks, which is not 100% as general as being able to resume any stack frame in what can become a tree of stack frames in the general case.  There's also the issue of whether lower stack frames are treated as copy-on-write or not, i.e. whether changes are isolated, when these frames are shared by multiple continuations.

'''[SS]''' Sure [jcw], what SC/GC does is to make you able to implement continuations without to write a stackless interpreter. Of course the Tcl stackframes
are to be copied (in the trivial implementation at least) but that's not a too big problem as it is as simple as to copy some hashtable and linked data
structure. The real problem is to write a stackless interpreter and given that it's a major work and that there are other systems to reach the goal why don't
use them.

'''[chi] 19Apr2005:''' I mean to remember, that Ruby does its continuation and thread thingy by simply copying the whole C stack from some point remembered during initialization of the interpreter up to the context of the calling C function. Switching back to that continuation simply copies back that remembered stack. So it works within C functions. Unfortunately setcontext und getcontext seem not to be widely available :-( Perhaps the same implementation as in Lua could be facilitated? In Lua, C context will not be remembered, AFAIK. So a C function has to come back. But a Lua function could be suspended. This restriction seems not to be too hurting, would it?


----
[Category Concept]