Am So., 9. Okt. 2022 um 15:26 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
>
> On Sun, Oct 9, 2022 at 3:07 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Am So., 9. Okt. 2022 um 14:46 Uhr schrieb Shiro Kawai <xxxxxx@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.

A composable continuation is just a continuous part of the stack
turned into a procedure.  It only interacts with the dynamic
environment when called when the continuous stack part captured
crosses a dynamic-wind boundary.  (And it is an error if the
continuous stack part contains a continuation barrier.)

Composable continuations can be compared to macro recording facilities
of typical application programs like Word.  When a continuation prompt
is set, the record button is pressed; when the composable continuation
is captured, the recording is stopped, and the recorded "macro" is
saved in a procedure.

> 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).

The following would not work:

(define g
  (make-coroutine-generator
    (lambda (yield)
      (unwind-protect
        (begin
          (yield 1)
          (yield 2))))))
(generator->list g)

(We have no cleanup forms here, but that's beside the point.)

If coroutine generators are implemented using first-class
continuations (as they are in the reference implementation), the
dynamic extent of the protected form is exited and reentered again,
which would be forbidden by the semantics of unwind-protect that is
under discussion. But this is probably expected.

By the way, this also shows that make-coroutine-generator in SRFI
121/158 is too underspecified and calls for a PFN. It just says that
the execution of PROC is suspended, but the latter does not seem to be
a Scheme technical term. In particular, it is not defined how it
interacts with the dynamic extent.

> 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?

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. If
implemented naively with first-class continuations, it would be a
problem. The SRFI 226 approach is to use current-parameterization,
call-with-parameterization, and call-in-initial-continuation.  They do
not trigger dynamic-wind handlers, nor do they cease to work in the
presence of continuation barriers.  This is important for the promise
semantics (that should be analogous to thread semantics) of SRFI 226.