On Sun, 9 Jul 2017 11:09:25 -0300 Vítor De Araújo <vbuara...@sapo.pt> wrote: > On 09/07/2017 09:59, Chris Vine wrote: > > On Sun, 09 Jul 2017 00:34:13 +0300 > > Marko Rauhamaa <ma...@pacujo.net> 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)?