Am So., 9. Okt. 2022 um 14:46 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
>
>
> On Sun, Oct 9, 2022 at 1:21 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Am So., 9. Okt. 2022 um 12:41 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>> >
>> > 1. Common Lisp's unwind-protect allows multiple cleanup forms.  Personally I don't see much benefit of allowing it, but to avoid confusions, we may adopt the same API.
>>
>> That's a good point. (I missed initially that there can be more than
>> one cleanup form.) Does CL execute the cleanup forms in order of their
>> appearance?
>
>
> Yes.  It's the same as (unwind-protect protected-form (begin cleanup-form ...))

Thanks; with my definition, I would have to code it like
(unwind-protect protected-form (begin (values) cleanup-form ...)) as
otherwise definitions would be allowed by the definition making it too
easy to write non-portable code.

>>
>>
>> > 2. This is more involved.  The cleanup forms of unwind-protect are literally for cleaning up, e.g. releasing resources.  This poses an issue in Scheme; with continuations, control can reenter protected-form.  Executing cleanup-forms in the after thunk of dynamic-wind invalides such applications as coroutines.
>>
>> Please note the appearance of `call-with-continuation-barrier` in my
>> proposed definition.  It is defined in SRFI 226. It is an error to
>> reinstate a continuation barrier, so escaping continuation in my
>> definition are allowed (triggering the cleanup forms), but returning
>> through a captured continuation is not.
>>
> I think I don't quite understand that part.  Is this allowed?  If so, does it output "15135" and returns 11?
>
> (call-with-continuation-prompt
>  (lambda ()
>    (+ 1
>       (call-with-composable-continuation
>        (lambda (k)
>          (call-with-continuation-barrier
>           (lambda ()
>             (dynamic-wind
>               (lambda () (write 1))
>               (lambda () (write (k 2)) 10)
>               (lambda () (write 5))))))))))
>
> If this isn't allowed, coroutines that capture continuation outside of unwind-protect can't be invoked within unwind-protect?

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

When SRFI 226 is available, the thread mechanism should be used to
implement coroutines.  This does not inter with dynamic-wind and
unwind-protect.  (In fact, coroutines through first-class
continuations are often too costly because of the presence of
dynamic-wind.)

Feel free to modify and repost your example in case not everything is clear.

Thanks,

Marc