A continuation behaves just like a one-arg function except it never returns to its caller. It returns to the point where it was created. This might upset the flow of the app server. Also, the app server relies on redirecting stdout to the network socket, and jumping to a saved continuation appears to restore stdout to whatever it was for that continuation.
I wonder if arc is intended to support full re-callable continuations - official arc only references 'ccc once, in the 'point macro, which is only used for 'catch. And the intent of 'catch (i think) is only to provide an escape mechanism, not a re-callable continuation.
I'm guessing that official arc uses ccc in a limited way because (I read somewhere that) arc was originally built on Common Lisp, not Scheme, and CL doesn't support full continuations. But I might be completely wrong. And maybe ccc is one of the reasons arc switched to scheme. Somebody on this forum knows the truth ...
i'm currently writing a blog post featuring Arc's ccc, and all signs point to it being a 100% implementation. this shouldn't be too surprising since (i believe) the compiler transforms the Arc code to CPS
i don't know what the OP is asking exactly, but the answer is likely yes. i implemented coroutines, so these more straightforward things should be no problem
i talk about it a bit on the blog post, but the problem with continuations is the freaken name. it sounds like some sophisticated thing, when in fact all it is is marking the next instruction. for example:
(ccc func)
obviously you're using ccc here because you want to go back to it later. perhaps you want to go back to it from within 'func'. in other words, so that 'func' effectively has the ability to arbitrarily return:
(ccc [do (stuff...)
(if blah (_ bleh)) ; early return
(do more stuff)])
but what if control returned right back precisely to ccc? then the whole form would be executed again. see how that would be a problem? so ccc doesn't mark the "current" spot. it marks the next spot so you don't get stuck in an infinite loop
and because it's the next spot, and because you can call _ as a function, they refer to it with the holistic name "continuation," instead of "the spot after the ccc"
they could have just as easily made the primitive be mark-the-current-spot, a la:
(ccc [= spot _])
but while making mark-the-current-spot with ccc is easy, the converse isn't, nor would mark-the-current-spot necessarily be the most common use form (the impetus for call/cc might have been to give scheme the ability to return)
Actually, arc just compiles everything down to Scheme; Scheme, of course, has full continuation support, and thus so does Arc.
That's a nice explanation of continuations, but one comment: I think (if I remember what I read correctly) that writing ccc in terms of mark-the-current-spot (or perhaps get/cc, or gcc :P) is actually impossible, but I could be wrong. The other advantage of ccc is that every flow control construct can be simulated using it (including, but not limited to, C's return).
> I think (if I remember what I read correctly) that writing ccc in terms of mark-the-current-spot (or perhaps get/cc, or gcc :P) is actually impossible, but I could be wrong.
that's the short-term conclusion i came to when i was fidding with it. i didn't exactly prove it was the case though so i was being safe
This is one of the few cases where it would be better to have some specifications other than the source code itself. A compliant implementation should support full continuations, because one could write programs that rely on ccc and those programs would work on ArcN.tar.
For example, consider the minor problem of macros such as 'w/infile:
(restartable
(pr "Press enter to begin processing the file")
(readline)
(w/infile p "thefile.txt"
(whilet l (readline p)
(when (is l "foo\n")
(prn "A \"foo\" was found in the file!")
(prn "Please correct these errors first")
(restart)))
(prn "finished processing!")))
The point is that 'restart is really a continuation bound to the beginning of the 'restartable form. Obviously 'w/infile and related forms must trap continuations; the mzscheme implementation uses 'dynamic-wind, exposed as the 'protect function.
This is one of the many cases where having an explicit specification would have been nice, because this would have required some code digging. What, exactly, is 'protect intended to do?
The problem is increased by the fact that the official arc implementation drains entire constructs (such as 'dynamic-wind) from the underlying scheme. How should we consider them when writing an alternative implementation? Are they intended to have the identical behavior of the corresponding scheme constructs? An official test suite would be really helpful and would solve most of the problems.
