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, 2 Jul 2017 12:58:31 +0100	[thread overview]
Message-ID: <20170702125831.192ddaec@bother.homenet> (raw)
In-Reply-To: <CAJ98PDxbY3654q0mEJBFVHMyQCsFwPvHP6J6KH5poS6k8jHJuQ@mail.gmail.com>

On Sun, 2 Jul 2017 08:00:58 +0200
Catonano <catonano@gmail.com> wrote:
> 2017-06-30 23:48 GMT+02:00 Panicz Maciej Godek
> <godek.maciek@gmail.com>:
> > It's very simple (at least from the point of view of a user)
> > When it is tempting to write something like
> >
> > (define (within-context action)
> >   (enter-context)
> >   (action)
> >   (leave-context))
> >
> > you simply change it to
> >
> > (define (within-context action)
> >   (dynamic-wind
> >     (lambda () (enter-context))
> >     action
> >     (lambda () (leave-context))))
> >
> > The thing is, that in general (action) may transfer control outside
> > of the scope of that particular context (like, using call/cc or
> > exceptions) -- and in such situations, we would like the
> > (leave-context) handler to be invoked. If and we ever get back
> > there, we wish that the (enter-context) were invoked again.
[snip]
> > Here's a simple real life example in Scheme:
> >
> > (define current-working-directory getcwd)(define change-directory
> > chdir)
> >
> > (define (with-changed-working-directory dir thunk)  (let ((cwd
> > (current-working-directory)))    (dynamic-wind (lambda ()
> > (change-directory dir))		  thunk
> > (lambda () (change-directory cwd)))))
> 
> aahh I see now
> 
> Well. the manual is not clear enough, I think, in this regard
[snip]
> I think that the use case should be explicitly stated, in the manual,
> as you did here
> 
> Also the example should be about some db or network connection, not
> about call/cc
> 
> So that understanding dynamic-wind and its use case wouldn t require
> understanding call/cc (which I still don t get)

Possibly the wording of the manual about dynamic-wind at
https://www.gnu.org/software/guile/manual/html_node/Dynamic-Wind.html#Dynamic-Wind
could be improved.  Stating that "If, any time during the execution of
thunk, the dynamic extent of the dynamic-wind expression is escaped
non-locally, out_guard is called" is a somewhat incomplete description
of when the out guard is called, since it is also invoked when the body
of the dynamic wind returns normally.  If you think the wording could
be improved I suggest you file a bug with a suggested wording.  Having
said that, I think that you are getting unnecessarily tied up with
call/cc rather than concentrating on the principle.

dynamic-wind is much more general than just for dealing with database or
network connections, which I think would be a poor focus for the manual.
dynamic-wind is relevant whenever control leaves the dynamic wind block
in question, either normally or by an exception or by invocation of a
specific continuation object such as via call/cc, call/ec or
abort-to-prompt.  Many languages have something similar - it is
analogous in some sense to a C# or Java finally block, which executes
whenever control leaves the associated try block, whether normally or by
virtue of an exception or a return, break, continue or goto statement.

The somewhat more unusual feature of dynamic-wind it that, because
the scheme language permits a dynamic context to be re-entered by the
invocation of a continuation object (say, as obtained by call/cc),
there is also an in guard made available to deal with entry into the
dynamic wind block.

Having said all that, dynamic-wind is not the answer to all cases where
control leaves a block of code non-locally.  It is best suited to cases
where invocation of a continuation object or the raising of an
exception fall to be dealt with in the same way, say by releasing a
resource such as by unlocking a mutex or closing a port.  But that is by
no means always the case - the invocation of a continuation object is
usually a deliberate programmatic strategy, whereas the raising of an
exception is usually not so and instead represents an unexpected
failure event of some kind in the program.

Chris



  parent reply	other threads:[~2017-07-02 11:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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     ` Chris Vine [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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   ` dynamic-wind Chris Vine
2017-07-17 10:04     ` dynamic-wind Catonano

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=20170702125831.192ddaec@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).