Am Mo., 10. Okt. 2022 um 09:25 Uhr schrieb Shiro Kawai <shiro.ka...@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.
