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

[Jon L White <edsel!jonl@labrea.stanford.edu>]

re: 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? 

This is exactly what Ron Goldman (of Lucid's QLISP project) and I mean
by "THROW commits"  -- that you execute the cleanup forms pending on the
unwind-protect frames, but you are "committed" _not_ to re-enter the bodies
without first exiting the CATCH to which you were throwing.  [But the local
variable environments are still guaranteed in existence during the cleanup-
form execution, since they can make reference to those variables.  Do I need
to be more specific here?]

I rather like your phraseology above -- using terms like "lifetime of a 
CATCH" etc.

Mabye the right approach to this miasma is to delete situation (1) from 
the current proposal, and then let it be passed; for we all seem to be in
agreement that it should be possible to "extend" a THROW in progress,
while aborting out of one particular cleanup-form execution.  Then, submit 
another proposal for the same issue which addresses only the situation (1) 
part.  Could you possibly take a stab at doing this before Larry's deadline?


re: 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.

I didn't realize you were the guilty party here. I think a lot of other 
people independently fell into this pit because of the obvious "re-entering 
the body without ever exiting the CATCH" capability, which would exist if 
situation (1) weren't proscribed.  My previous msg described it thus:
    "As someone has said previously, this proposal isn't about proscriptions 
     against writing looping code -- e.g., (prog () A (go A)) -- but about the
     dynamic scoping relations between THROW and UNWIND-PROTECT cleanups.  
     [Well, if they didn't say exactly that, they should have!]"

Also, I think a proposal about case (1) will have to address the 
CATCH-BARRIER implication, if for no other reason than that someone 
actually claimed that he wanted to erect a barrier using the mechanism 
of situation (1) scoping.  At the very least -- if it is such good idea 
to permit catch barriers -- then an explicit proposal for CATCH-BARRIER 
(or CATCHALL, or whatever) should be put forward (and hopefully defeated);
otherwise one is subject to the _unintentional_ falling into an unseen 
barrier simply because of poor scoping on THROW's.  Jim MacDonald's reply 
to KMP seems to me to show that an unrestricted CATCH-BARRIER really isn't 
needed for an sensibly-written program; and whatever arguments kept 
CATCH-BARRIER out of Common Lisp in 1983 are probably still relevant today.



-- JonL --