Bradley Lucier wrote:
On Jun 27, 2007, at 8:35 AM, Marc Feeley wrote:
On 25-Jun-07, at 4:27 PM, naruto canada wrote:
Does gambit-c have call/ec? Thanks.
Call/ec is not predefined. You can define it yourself like this:
(define call/ec call/cc)
Obviously, in this case the implementation of call/ec is not as fast as it could be.
Marc:
Is there some combination of continuation-capture and continuation- graft that gives the semantics of call/ec?
To be honest, I don't understand what any of call/ec, continuation- capture, and continuation-graft do.
In my honest experience:
##continuation-capture is just call/cc but gives the raw continuation data type without wrapping as a procedure. (It's a bit faster because of this.)
##continuation-graft (there is no |continuation-graft|, right, or has this been added recently?) is quite nifty, it runs the given thunk in the context of a given continuation (it needs the raw continuation as given by ##continuation-capture). See http://scheme.mine.nu/gambit/scratch/cj-exception/ for an example (the idea of this module is to provide exception values which are restartable later, e.g. to be serialized and stored to disk and provided for debugging later on). Actually you should use the -with-winding functions as shown so that dynamic-wind works. What the shown code does: capture the (raw) continuation from where an exception happened, wrap it together with the exception value in a cj-exception structure, and call the user-provided exception handler with it in the context of the code outside of the with-exception/continuation-catcher (e.g. the dynamic environment from outside has already been reinstantiated and exceptions thrown from |handler| will thus call the next outer current-exception-handler instead of looping into the inner one).
As far as I understand, call/ec would return a continuation which can only be instantiated once and only from the dynamic scope of their capture (like exceptions in languages without 1st class continuation support).
Christian.