Unwind-protect
Marc Nieper-Wißkirchen
(09 Oct 2022 09:56 UTC)
|
Re: Unwind-protect
Shiro Kawai
(09 Oct 2022 10:41 UTC)
|
Re: Unwind-protect Marc Nieper-Wißkirchen (09 Oct 2022 11:21 UTC)
|
Re: Unwind-protect
Shiro Kawai
(09 Oct 2022 12:46 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(09 Oct 2022 13:07 UTC)
|
Re: Unwind-protect
Shiro Kawai
(09 Oct 2022 13:26 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(09 Oct 2022 13:58 UTC)
|
Re: Unwind-protect
Shiro Kawai
(09 Oct 2022 22:50 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(10 Oct 2022 05:57 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(10 Oct 2022 07:24 UTC)
|
Re: Unwind-protect
Shiro Kawai
(10 Oct 2022 07:25 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(10 Oct 2022 07:39 UTC)
|
Re: Unwind-protect
Shiro Kawai
(10 Oct 2022 08:57 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(10 Oct 2022 08:59 UTC)
|
Re: Unwind-protect
John Cowan
(09 Oct 2022 15:03 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(09 Oct 2022 15:13 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(09 Oct 2022 15:39 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(09 Oct 2022 16:13 UTC)
|
Re: Unwind-protect
Lassi Kortela
(09 Oct 2022 15:41 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(09 Oct 2022 16:11 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(28 Oct 2022 11:08 UTC)
|
Re: Unwind-protect
Vincent Manis
(28 Oct 2022 18:53 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(28 Oct 2022 18:58 UTC)
|
Re: Unwind-protect
Vincent Manis
(28 Oct 2022 19:14 UTC)
|
Re: Unwind-protect
Marc Nieper-Wißkirchen
(28 Oct 2022 19:28 UTC)
|
Re: Unwind-protect
Arthur A. Gleckler
(28 Oct 2022 19:31 UTC)
|
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? > 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. Does it solve your second issue? > I don't think there's a clear solution, for there's no way to know for sure if the control transfer out of protected-form is final. In Gauche, we transfer (unwind-protect protected-form cleanup-forms ...) to roughly this code: > > ==== > (let ((done #f)) > (define (cleanup) > (unless done > (set! done #t) > cleanup-form ...)) > (guard (e ((condition-has-type? e <serious-condition>) > (cleanup) > (raise e)) > (else (raise e))) > (receive r protected-form > (cleanup) > (apply values r)))) > ==== > > This code relies on some Gauche-specific behaviors. > (Actual code is a lot more messy for it accesses Gauche runtime internals) > > - Gauche's exception system predates srfi-34 etc, and our <serious-condition> isn't allowed to be continuable. We only call cleanup forms when a serious condition is thrown (or protected form exits normally). > - If controls goes out with other type of conditions, cleanup forms aren't executed, for the condition may be continuable. It's up to the user to deal with the consequences. If the cleanup forms are so important, translate conditions to serious ones in protected forms. > - Control transfers other than raise/error don't trigger cleanup forms. It's up to the user to ensure such control should return to the protected-form eventually. > - If a continuation is captured in protected-form, and it exits normally, and then the control reenters to protected-form again, cleanup forms are no longer invoked. Supposedly it has already committed irreversible action. The second execution of protected-form may access to the already released resources and causes an error; it's up to the user to deal with the consequence. > > I know it is a pretty leaky abstraction. But executing cleanup forms in the after thunk won't coexist with continuation based coroutines. > > > > > > > > > > > On Sat, Oct 8, 2022 at 11:56 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote: >> >> John Cowan suggested that SRFI 226 should include a version of Common >> Lisp's unwind-protect suitable for Scheme. >> >> In [1], I replied after some discussion with the following proposal >> for a definition of a Scheme unwind-protect: >> >> (define-syntax unwind-protect >> (syntax-rules () >> ((unwind-protect protected-form cleanup-form) >> (call-with-continuation-barrier >> (lambda () >> (dynamic-wind >> (lambda () (values)) >> (lambda () protected-form) >> (lambda () cleanup-form))))))) >> >> As I think it is essential to get this famous form right when included >> in a fundamental SRFI like SRFI 226, I would like to hear more >> opinions on the above form. >> >> (It should be noted, that Scheme procedures like >> `call-with-input-file` are not based on unwind-protect semantics.) >> >> Should there be no consensus on unwind-protect, it is probably better >> to reserve an extra SRFI for it (which, in turn, can depend on SRFI >> 226). >> >> Thanks for taking a look, >> >> Marc >> >> -- >> >> [1] https://srfi-email.schemers.org/srfi-226/msg/20888154/