Re: Issue: EXIT-EXTENT (Version 4)

["Steve Bacher (Batchman)" <SEB1525@draper.com>]

I am strongly in favor of EXIT-EXTENT:MEDIUM, since this is how my 
implementation works.  Normally that would not be reason enough, but the
implementational details are not limited to THROW's stack-combing.  GO and
RETURN-FROM in compiled code, for example, in conjunction with CATCH and
UNWIND-PROTECT, require a lot of careful planning to unwind the correct
exit environments, which is done in a semi-static way for maximum
efficiency - no THROWing around underlying tags here!  
 
I don't agree with your statement that "all currently valid implementations
will continue to be valid with the MINIMAL proposal", or whatever it was
that you said.  Perhaps that is true in a very limited sense - i.e. that
if it "is an error" to THROW out of a cleanup form in one of those 
screw-case examples, having the implementation do the "other" thing is
one manifestation of "is an error"... but what about cases where there
is a further-outlying environment which can get exited to?  Or is the
talk about a CATCH tag being valid but inactivated, like a BLOCK name.
supposed to prevent any nonlocal exit from a cleanup form from ever
working without error?  In any case, I have a lot of trouble with the
notion of an inactive CATCH tag, both conceptually and implementationally.
 
Please clarfify:  If an implementation conforms to EXIT-EXTENT:MEDIUM, then
if EXIT-EXTENT:MINIMAL is adopted will said implementation be correct or
in error?