Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

The inclusion of situation 2 distracts from the issue, since as far as I
know there is no controversy over situation 2, only over situation 1.  Also
there is at least one typo where the proposal says 2 where I think it means
1, which detracts from its understandability.

The attempt to explain UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:CONTINUATION-MODEL
in terms of continuations explains nothing, since Scheme's continuation
semantics says nothing about dynamic lifetime and indeed assumes indefinite
lifetime for continuations.  Since the controversy revolves entirely around
precisely when the dynamic (as prescribed by Common Lisp) lifetime of a
continuation ends, appeals to a semantics with indefinite lifetimes cannot
shed any light on the issue.

In retrospect, all the stuff about looping and unstoppable programs was a
distraction from the real issue, which only enables people to flame instead
of thinking about the real issue.  I'm sorry I brought it up, and I wish
it were removed from the proposal and people would stop talking about it.

The real issue is very simple: CLtL pages 120 and 139 say that blocks and
catches have dynamic lifetime and can only be exited once.  When it is
exited, the dynamic lifetime of a block or catch ends.  Furthermore,
although CLtL does not actually say so, it surely means to imply that
when a block or catch is exited, the dynamic lifetime of any blocks or
catches dynamically nested inside it also ends.

Here's the issue: can a portable program assume that the lifetime of a
block or catch ends at the last possible moment, when control reaches
the caller of the block or catch?  Or must portable programs assume that
this lifetime ends at the first possible moment, when THROW has decided
not to signal the error mentioned in the last sentence (outside of
notes) on CLtL p.142?  I maintain that the semantics should be defined
in the way which is most restrictive on portable programs and least
restrictive on implementations, that is, portable programs must assume
that the lifetime ends at the first possible moment that CLtL allows it
to end.

I suppose if I want anyone to listen to me, I have to find the time to
write up an alternative proposal.  I will try to find that time in the
next couple of days, but can't promise anything.  Fortunately, my 
alternative proposal will be much shorter, as it will not be padded
out with things I consider digressions.