[RAM: exiting from unwind protects]

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

I find the following pretty persuasive...

Date: Saturday, 2 May 1987  11:16-EDT
 From: Rob MacLachlan <RAM>
To:   fahlman
Re:   exiting from unwind protects
ReSent-Date: Sun 10 May 87 10:56:56-EDT
ReSent-From: Rob.MacLachlan@C.CS.CMU.EDU
ReSent-To: fahlman@C.CS.CMU.EDU
ReSent-Message-ID: <12301270482.15.RAM@C.CS.CMU.EDU>

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
environment solutions.  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 
(makunbound '*terminal-io*)?

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
    error?
      (block block
        (unwind-protect <foo>
          (return-from block)))
    Does this?
      (unwind-protect <foo>
        (block block
          (return-from block)))

 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
    they try.

 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
    debugger?

If I had ever been screwed by this, I would think differently.  I'm
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
error.

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.  Any alternative must somehow
introduce an "in an unwind protect cleanup" marker into the dynamic
environment of the cleanup forms.

  Rob