Subject: Re: newbie: non local exits in CL
From: Erik Naggum <>
Date: 1997/07/12
Newsgroups: comp.lang.lisp
Message-ID: <>

* Kent M. Pitman
| Right.  In fact, since UNWIND-PROTECT was also mentioned, ... 
| It is ALMOST ALWAYS better to simply write:
|  (let ((old-value (figure-out-some-state)))
|    (unwind-protect (...whatever...)
|      (restore-state old-value)))

sorry for butchering a fine article, but I have discovered something I
found to be quite hard to do in a reasonable manner.  I first saw it in
Emacs Lisp, which can become quite seriously confused if you interrupt it
in the middle of some cleanup-forms that take non-zero time to complete.
Common Lisp the Standard reads:

# `unwind-protect' evaluates protected-form and guarantees that
# cleanup-forms are executed before `unwind-protect' exits, whether it
# terminates normally or is aborted by a control transfer of some kind.
# `unwind-protect' is intended to be used to make sure that certain side
# effects take place after the evaluation of protected-form.

if some interrupt can occur at any time in the protected-forms, it stands
to reason that it might as well occur in the cleanup-forms, especially if
it's a user hitting an interrupt key repeatedly.  in Emacs, I experimented
with delaying quits (Emacs' name for handling a user's C-g) until after the
cleanup-forms had terminated, but it had the nasty side effect of making
Emacs uninterruptible in several cases.

so, how strong is the wording "guarantees that cleanup-forms are executed
before `unwind-protect' exits", considering that it is left open _how_ the
`unwind-protect' is exited, presuming that it could also be exited

under Unix, good programmers have become used to wrap critical code in a
whole lot of silly tests for error returns form everything under the sun,
but they still need a way to guarantee that a sequence of operations has
been completed before some other operation is started, and they have the
ability to belay all signals during critical regions.  even though this is
Unix-centric, I imagine there must have been a way to obtain a similar
guarantee of completed sequences of operations even in the absence of an
ill-designed error return policy like Unix'.  (I don't know much about
real-time programming, but it appears to me that such a question would have
had to be asked and answered in real-time systems.)

if DUI is "Driving Under the Influence"
then GUI must be "Graphics Under the Influence"