Here is a correct (in the sense of space-leakiness and compatibility
with continuation barriers) version of make-coroutine-generator:

(define make-coroutine-generator
  (lambda (proc)
    (define tag (make-continuation-prompt-tag))
    (define yield
      (lambda (val)
        (call-with-composable-continuation
         (lambda (c)
           (set! k c)
           (abort-current-continuation tag (lambda () val)))
         tag)))
    (define k
      (lambda ()
        (proc yield)
        (eof-object)))
    (define g
      (lambda ()
        (call-with-continuation-prompt k tag)))
    g))

Note how nice it is that the eof object can be handled as an ordinary
return value.

This, however, is not the only possible interpretation of SRFI 158's
make-coroutine-generator. With the above code, the procedure's forms
are evaluated in the dynamic extent (and with the parameterization) of
the call "(g)" of the returned generator. If we don't want this but
want coroutine generators modeled like promises and threads, we have
to modify the code to get:

(define make-coroutine-generator
  (lambda (proc)
    (define ps (current-parameterization))
    (define tag (make-continuation-prompt-tag))
    (define yield
      (lambda (val)
        (call-with-composable-continuation
         (lambda (c)
           (set! k c)
           (abort-current-continuation tag (lambda () val)))
         tag)))
    (define k
      (lambda ()
        (proc yield)
        (eof-object)))
    (define g
      (lambda ()
        (call-in-initial-continuation
          (lambda ()
            (call-with-parameterization ps
              (lambda ()
                (call-with-continuation-prompt k tag)))))))
    g))

I think, this is what we really want and this should be specified in
an addendum to SRFI 158.

Am Mo., 10. Okt. 2022 um 07:57 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:
>
> Am Mo., 10. Okt. 2022 um 00:50 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> [...]
>
> > I think it's ok for the above not to work.  My concern is more like this one:
> >
> > (let ((p (make-parameter 0)))
> >    (define g (make-coroutine-generator (lambda (yield)
> >                                                                 (parameterize ((p 1))
> >                                                                     (yield p)
> >                                                                     (yield p)))))
> >    (unwind-protect
> >       (parameterize ((p 2))
> >          (list (g) (g)))
> >       )
> >
> > If parameterize is realized with dynamic-wind, can this work?
>
> Dynamic-wind alone is not a problem because it does not remove or
> reinstall continuation frames. That said, by SRFI 226, dynamic-wind
> cannot be implemented using dynamic-wind because the last expression
> of the body of a parameterize form must be in tail context if the
> parameterize form itself is in tail context.
>
> The code above works because the generator procedure is not run
> outside the dynamic extent of the unwind-protect form.  It would be a
> problem if the generator were started outside and continued inside
> because this would mean jumping in and out of the dynamic extent of
> the unwind-protect form.
>
> But the real problem lies in the SRFI 158 implementation of
> make-coroutine-generator using call/cc. Besides that the dynamic
> environments, in which the forms of the generator body are evaluated,
> is not well-defined, using call/cc leaks space (in a way discussed in
> the rationale of SRFI 226). With SRFI 226 available,
> make-coroutine-generator should be rewritten with delimited
> continuations.
>
> >> You mean dynamic-lambda from SRFI 154? That should be considered
> >> subsumed and deprecated by SRFI 226. (I should ask Arthur to withdraw
> >> it when SRFI 226 is finalized.) Your question seems to be less about
> >> composable continuations, and more about dynamic-lambda.
> >
> >
> > Yes, I meant srfi-154.  What I'm trying to do is to undersand composable continuations wrt dyanmic environment.  Initially I thought it's like a variation of delimited continuations, but seems that there's a subtle difference so I have to follow the srfi explanation more closely.
>
> Composable continuations are delimited continuations. I use the
> adjective "composable"  because, principally, even undelimited
> continuations are delimited (by the primordial prompt whatever that is
> in the context).