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.
As far as I can write such coroutine using srfi-226 procedures, I'll
rewrite existing libraries.
On Sun, Oct 9, 2022 at 7:57 PM Marc Nieper-Wißkirchen <marc.nie...@gmail.com>
wrote:
> Am Mo., 10. Okt. 2022 um 00:50 Uhr schrieb Shiro Kawai <
> shiro.ka...@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).
>
