Re: dynamic-wind

[Chris Vine]

On Sun, 9 Jul 2017 11:09:25 -0300
Vítor De Araújo <address@hidden> wrote:
> On 09/07/2017 09:59, Chris Vine wrote:
> > On Sun, 09 Jul 2017 00:34:13 +0300
> > Marko Rauhamaa <address@hidden> writes:  
> >> Hm. Python's try/finally has several uses in virtually every
> >> program.
> >>
> >> Trouble is, Scheme's continuations make it impossible to know when
> >> something is really final.  
> >>
> >> In fact, implementing coroutines and cooperative multitasking using
> >> continuations almost guarantee a repeated back-and-forth through
> >> dynamic-wind.
> >>
> >> I strongly suspect Scheme's continuations are more trouble than
> >> they are worth.    
> > 
> > I disagree with that.  On the first point, you know that a
> > dynamic-wind block can no longer be re-entered (if that is what you
> > mean by "really final") when the continuation object concerned is
> > no longer accessible.  At that point it, and all references to
> > other objects encapsulated by the continuation, will be released in
> > the ordinary way.  You also know the same when your continuation is
> > only an escape continuation.  
> 
> That helps the implementation know if a continuation will not be
> entered again, but it does not help when you want to do the kinds of
> things you do with unwind-protect or try/finally in other languages.
> For example, with unwind-protect, you can open a port or another
> resource and ensure it will be closed if control escapes the
> unwind-protect form. You can do that with dynamic-wind, but it is
> less meaningful to do so because control can be re-entered again.
> There is no language construct (as far as I know – maybe there is in
> Guile) that can detect that flow has exited the form and *will never
> enter it again*. So the presence of continuations make operations
> like unwind-protect less meaningful. I don't know what is the Scheme
> way to address these situations.

unwind-protect is a dynamic-wind without the in guard.

The scheme way of dealing with re-entry (which is not possible in
common lisp) is to initialize in the in guard the resources to be
released in the out guard.  There are two problems: first it may be you
cannot do that - you may need to initialize the resources elsewhere and
it may not be meaningful anyway to re-initialize them - see below.
Secondly there is no uncomplicated way of distinguishing between
non-local exit on invocation of a continuation object, non-local exit
on the throwing of an exception and a normal exit, but the required
treatment may be different in each case.  Obviously you can distinguish
using flags and so forth, but it is a pain.

There is a language construct in guile for knowing whether a
continuation object is a full continuation or an escape continuation:
call/cc produces full continuations and call/ec produces escape
continuations (which cannot be re-entered).  call-with-prompt produces
re-enterable delimited continuations.

As I said, dynamic-wind is a very blunt instrument.  I find it useful
only for very local resources of a particular kind.  Releasing a mutex
is a common case where dynamic-winds are useful (guile has the
with-mutex form).  Ports, as in your example, are not as clear cut.
Sure, you may want to close the port when you exit a particular block
in the case of a normal exit, an exception or an escape continuation,
but do you necessarily want to do so if you might re-enter later and
closing the port is a destructive operation (it vacates input buffers)?