[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RAM: exiting from unwind protects]
- To: cl-cleanup@SAIL.STANFORD.EDU
- Subject: [RAM: exiting from unwind protects]
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 13 May 87 00:02 EDT
- In-reply-to: <FAHLMAN.12301313646.BABYL@C.CS.CMU.EDU>
Date: Sun, 10 May 1987 14:54 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I find the following pretty persuasive...
I don't. Actually it seems to be mostly irrelevant to the issue at
hand. Here's some commentary on it. Feel free to show this to RAM if
Date: Saturday, 2 May 1987 11:16-EDT
From: Rob MacLachlan <RAM>
I don't really agree with Moon about this thing. I certainly knew about
about the feature of being about to write something that you can't exit
from using any common lisp facility, but I don't see this as a
"serious environment bug". Our system has always has this property.
When someone first pointed out this property of Common Lisp way back
when, I did in fact write the pathological example and it did in fact
behave in the pathological fashion. After a while I got bored of
trying to throw out of the break loop, and I quit.
If I had really been doing anything, I could always have skipped over
the losing frame using debug-return. Environment problems can have
I don't know what debug-return is (presumably something in the Spice
Lisp environment). Unless it's something that bypasses unwind-protect
and deliberately doesn't evaluate the cleanup forms, I don't think it
solves the problem. However, I agree that environment problems can have
environment solutions, and I think the issue is to make sure that the
language doesn't forbid the environment from solving this by trying to
enforce a particular semantics for the pathological construct, instead
of having it be an error.
In any case, I could have saved work I was
doing from the break loop. This feature certainly isn't a big deal;
there are lots of ways a malicious Lisp user can blow the system out
of the water. What happened the last time you did
The second paragraph on p.329 appears to say that it is invalid for a
portable program to do that. What I am arguing for is a similar
restriction on portable programs doing the similar thing with
unwind-protect and throw. So I think this example actually supports my
In contrast, it seems to me that all the "fixes" for this problem
result in substantial increases in the complexity of the language
defintion for no gain. It seems that Moon has already introduced
three new things into the language:
1] The concept of "throwing out of an unwind protect cleanup". When
are you in an unwind protect? What does it mean to throw out of
it? Does this apply to lexical exits too? Does this signal an
Most of this would be answered by re-reading the relevant proposal to
the cleanup committee (are these archived someplace public?), which
was not written by me. I agree that we need a better-written version
of that proposal that is easier to understand and less ambiguous. The
one I am looking at is
Edit history: Revision 1 by KMP 02/27/87
My only contribution to the discussion was
in the message <870423020745.9.MOON@EUPHRATES.SCRC.Symbolics.COM>.
Here are some relevant excerpts from the referenced proposal:
If a non-local return is done while in the cleanup form of an
UNWIND-PROTECT, the behavior is not always well-defined.
There are three basic cases:
1. Transfer to a point inside the point to which control
would have transferred.
and what I proposed in answer to this was to do one of three
things in case 1, transfer to a point inside the point to
which control would have transferred.
1. wimp out and say it "is an error"
2. signal an error
3. resume the original throw, just as if the cleanup handler had
I prefer signalling an error, because I firmly believe that the program
Note that I have not introduced any new concepts here. I don't think
the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT proposal introduced new
concepts either; it just made explicit reference to concepts that
were already in Common Lisp. The argument that these concepts make
the language definition too complex seems to be an argument that the
language definition should not attempt to define the semantics of throwing
2] The concept of errors that aren't errors, which we need so that
users can't screw themselves with this feature no matter how hard
Last time I read the "error proposal" it included this concept. I don't
think I invented it, I just borrowed it from there while writing up the
discussion of throw vs. unwind-protect. Certainly in the absence of the
error proposal this concept is not introduced into the language, since the
language currently does not contain an IGNORE-ERRORS construct, nor any
other construct that is sensitive to the issue.
3] The implicit requirement that an implementation have some exit
mechanism other than throw so that it can unwind out of cleanup
forms even if the user can't. What does the system do when you
are running in an unwind protect and the user types an interrupt?
In fact, it seems that Moon is being inconsistent here, since he
has already assumed that interrupts do throw. If the user
interrupts when running in a cleanup do you signal an error, and
then signal an error whenever the user tries to abort out of the
All of point 3 appears to be a misunderstanding of what was being
discussed and proposed. "Transfer to a point inside the point to which
control would have transferred" is irrelevant to "the user types an
interrupt" (which I take to mean something like Maclisp's control-X
and control-G, i.e. abort the program and return to a read-eval-print
loop) since those would be transfers to a point outside of, or equal to,
any throw currently in progress.
If I had ever been screwed by this, I would think differently.
The inside-Symbolics component of this discussion originated with a
customer being screwed by this.
sure that most of the reason that this problem doesn't happen is that
people usually don't write code that aborts from unwind protect
cleanups. There is a big difference between saying that something is
rarely needed and possibly dangerous and saying that it must signal an
I am convinced that the simplest evaluation model is to say that the
unwind-protect cleanup is evaluated in the lexical and dynamic
environment of the unwind-protect form.
Nobody ever proposed anything different as far as I am aware.
Any alternative must somehow
introduce an "in an unwind protect cleanup" marker into the dynamic
environment of the cleanup forms.
The issue is actually what happens you nest throws (throughout this
discussion "throw" has been understood to include all non-local exits,
not only the THROW function). Thus the marker in question is "in throw",
not "in an unwind protect cleanup".
Yes, the dynamic state of a program that is throwing would need to
include an indication of where it was throwing to if we were to adopt
the proposal that misnested throws signal an error or the proposal that
they resume the outer throw. In the "is an error" case, there are no
requirements on the implementation, and the requirement is only that
portable programs cannot assume any particular behavior. However, I
can't imagine an implementation of throw that does -not- remember in its
dynamic state where it's going to throw to when it finishes evaluating
some unwind-protect cleanup forms.
To get back to earth after all this lofty flaming, remember that the
specific case mentioned in the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
and the question is: what does the THROW to BAR do? One possible answer
that many people seemed to favor is it throws to BAR and the throw to
FOO never happens. The answer I prefer is that this is not a valid
Common Lisp program. Does this make the issue clear?