On Sun, Oct 9, 2022 at 3:07 AM Marc Nieper-Wißkirchen <marc.nie...@gmail.com> wrote:
> Am So., 9. Okt. 2022 um 14:46 Uhr schrieb Shiro Kawai < > shiro.ka...@gmail.com>: > > Your example prints "135" and evaluates to 11. The composable > continuation captured in the variable K is an ordinary procedure. > Invoking it does not remove any continuation frames. In particular, > the dynamic extent of the THUNK in dynamic-wind is not left. > > On the other hand, coroutines implemented through call/cc would not be > allowed because this would mean that a non-composable continuation is > captured within the dynamic extent of call-with-continuation-barrier > (which itself is fine) and then later reinstated outside of that > dynamic extent (which would raise a &continuation condition object). > Thanks. I think not allowing non-composable continuations reentering unwind-protect is rather desirable. It solves the issue of traditional continuations that you can't know whether the control will come back or not. I need to understand more about composable continuations not interacting with a dynamic environment. By "coroutine", what I have in mind is something like make-coroutine-generator of srfi-158. If the implementation uses native threads for Scheme threads, using a thread for a coroutine generator is too much overhead. Using delimited continuations can be lighter. However, if I do so, it seems to require interacting with a dynamic environment, doesn't it? (I need to think more to come up a concrete example). Also, how would it work if invoking composable continuations involves calling a procedure created by dynamic-lambda? Won't it require unwinding dynamic-wind handlers?
