Basically the most important realization is that the return address on the stack may be modeled as the address for a different procedure, which by a staggering coincidence just so happens to point to the code after the function call. So basically a return is itself equivalent to a function call.
ccc is one of the strangest things in Scheme (and Arc now). Hard to get everything behind it, but it can be used to implement return statements, try-catch à la C++/Java, coroutines à la Lua, generators à la Python and of course continuation-based web apps à la Arc...
A very strange beast, and as far as I know the thing Scheme has that CL hasn't (and cannot trivially implement).
Actually, the form of closure used by Arc is highly similar to a continuation passing style, so although it doesn't use 'ccc, it does use continuations.
cl-cont is a library that implements closures and runs on many CL implementations. So it's not a matter of CL can't do it, CL just has to use a library to do it.
I think there are conceptual problems mixing unwind-protect-like constructs and call/cc.
The cl-cont lib appears to only support a subset of CL (in particular unwind-protect is not supported).
So cl-cont doesn't demonstrate that CL can support it, only that a restricted subset of CL can.
I don't know if it is possible to sensibly accommodate unwind-protect and call/cc in the same language, it seems smarter people than I have avoided doing so.
Scheme's dynamic-wind serves the same purpose as unwind-protect (except with entry conditions as well, since a continuation could suddenly return into your protected code), and plays nicely with continuations. I'm not sure about the details, though.
Thanks for that, pretty interesting. I guess that makes writing entry and exit conditions a little more interesting, since they could end up being invoked multiple times.
