> 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