Call/cc is definitly a beast (but it can be a useful one).
But there is no need to go that far just because you use
continuations.

The idea of continuations is very simple:
instead of having a function return its result, the function
will get passed an extra argument; this extra argument is
a function that will be given (i.e. called with) the result at
the point where a regular function would have returned.

There, that wasn't so bad, was it? :)

	-- Lennart


Gordon Waidhofer wrote:
>>Do you have any recomended reading for those of us who aren't 
>>familiar with continuations? :-)
> 
> 
> There are surely better answers, but here's an answer....
> 
> Continuations are hard to sum up in a nutshell. See the
> Scheme procedure call-with-current-continuation, aka call/cc.
> I tried to find a short, illuminating description. Short is
> possible. Illuminating, well.....
> 
> Continuations proper can be thought of as setjmp/longjmp
> on steroids. If foo() calls setjmp(jb), you can not pass
> jb to longjmp() after foo() returns. That's setjmp()/longjmp().
> But call/cc allows "unlimited extent", meaning jb remains
> valid until you abandon it or kill it. You can even use jb
> an unlimited number of times. It amounts to copying
> the stack. That's continuations proper, in a nutshell. It is
> a pale explanation compared to what's possible.
> 
> The kcont mechanism posted is a nice framework for
> callbacks, as the poster (Johnathon Stone) said.
> I can see how it took its inspiration from continuations.
> All the fiddling to get spls() right for callbacks,
> sequencing, off-level deferal, etc, etc, are kinda
> bundled up here. It looks like one of those things
> that, once you get used to it, you wonder how you did
> without it. We all do the same sorts of things all
> the time without the framework.
> 
> FWIW,
> 	-gww
> 
>