Am Mo., 10. Okt. 2022 um 09:25 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> I have no problems rewriting make-coroutine-generator to suit for srfi-226; in fact, Gauche's one is already written using delimited continuations (shift/reset).
> My concern is still whether srfi-226 allows (delimited) continuation-based coroutine to coexist seamlessly with unwind-protect.
> E.g. such coroutine based generator may be created by a third party and passed to my routine where I want to use unwind-protect:
>
> (lambda (g)
>    (unwind-protect
>         (... using (g) ...)
>      (cleanup)))
>
> (g) may already be called and have captured dynamic environments elsewhere.

Yes, this will work with a version based on delimited continuations.
It would be a problem if the dynamic extent of the procedure's body of
the coroutine generator is left and re-entered outside of yield while
processing the body. But this is expected of what we want from
unwind-protect.

(define g
  (make-coroutine-generator
    (lambda (yield)
      (call/cc
        (lambda (c)
          (abort-current-continuation (default-continuation-prompt-tag) c))))))

Here, the abortion to the default continuation prompt tag would leave
the dynamic extent of the generator procedure and thus of
unwind-protect. It will be reentered when the default prompt handler
invokes C.

With the second version of my make-coroutine-generator implementation
above, even this problem goes away: As the coroutine generator
procedure is evaluated in an initial continuation, no outside
continuation prompt would be visible.

> As far as I can write such coroutine using srfi-226 procedures, I'll rewrite existing libraries.

Great! Also, the specification of coroutine generators has to be made precise.