This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
> I don't think this gets you all the way home. For example, assume K > is a continuation -- something we made with CALL/CC. This won't work: > (k (thunk)) > That sort-of punts the current continuation and "installs" K as > the continuation for the THUNK call. But a simple implementation of > Scheme wouldn't even realise that K was a continuation until THUNK > had returned -- we wanted to punt the current stack eagerly, *before* > we leapt off to THUNK. See the problem? Yes, what you want are the procedures (continuation-capture receiver) (continuation-graft cont thunk) (continuation-return cont result) which are defined at the end of this message. They only rely on call-with-current-continuation. I'm hoping to write a short paper on this for the Scheme workshop. > But put into SRFI-18 some *generic* language saying that dynamic binding > facilities should be part of the continuation, hence threads pick up > a new dynamic env on a continuation throw. > > How do you like that? > -Olin Fair enough. Marc (define (continuation-capture receiver) ((call-with-current-continuation ; note important extra paren! (lambda (cont) (continuation-return cont (receiver cont)))))) (define (continuation-graft cont thunk) (cont thunk)) (define (continuation-return cont result) (continuation-graft (lambda () result))) ; a test (begin (write 1) ; written to stdout (continuation-capture (lambda (cont) (with-output-to-file "foo" (lambda () (write 2) ; written to the file "foo" (continuation-graft cont (lambda () (write 3))) ; written to stdout (write 4))))) ; never written (write 5)) ; written to stdout