unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Chris Vine <vine35792468@gmail.com>
To: guile-user@gnu.org
Subject: Re: dynamic-wind
Date: Sun, 9 Jul 2017 15:49:28 +0100	[thread overview]
Message-ID: <20170709154928.170385a5@bother.homenet> (raw)
In-Reply-To: <59623915.6070104@sapo.pt>

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



  reply	other threads:[~2017-07-09 14:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-09 12:59 dynamic-wind Chris Vine
2017-07-09 14:09 ` dynamic-wind Vítor De Araújo
2017-07-09 14:49   ` Chris Vine [this message]
2017-07-17 10:04     ` dynamic-wind Catonano
  -- strict thread matches above, loose matches on Subject: below --
2017-06-30 20:33 dynamic-wind Catonano
2017-06-30 21:48 ` dynamic-wind Panicz Maciej Godek
2017-07-02  6:00   ` dynamic-wind Catonano
2017-07-02  6:01     ` dynamic-wind Catonano
2017-07-02 11:58     ` dynamic-wind Chris Vine
2017-07-05  6:14       ` dynamic-wind Catonano
2017-07-05  8:23         ` dynamic-wind David Kastrup
2017-07-08 20:03         ` dynamic-wind Amirouche Boubekki
2017-07-08 21:34           ` dynamic-wind Marko Rauhamaa
2017-07-09  7:21             ` dynamic-wind David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170709154928.170385a5@bother.homenet \
    --to=vine35792468@gmail.com \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).