Re: issue EXIT-EXTENT

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

OK, it's starting to make some sense now.  I think the thing that was
confusing me the most was the use of the noun "exit" to refer to the
thing that is being exited *from*, while I was interpreting it as its
dictionary definition as "the act of leaving".  Things would be much
more understandable if the writeup avoided this terminology and just
talked about the dynamic extent of CATCH, BLOCK, and TAGBODY forms.

Now that I think I understand the proposal, I see a serious problem.
In the implementation I did for the Atari ST, UNWIND-PROTECT cleanup
forms are executed with all outer CATCHes still in place.  It seems to
me like this falls into the category of the second paragraph in the
"Current Practice" section, and that this is legal according to CLtL.

Consider the case:

(defun test ()
    (catch 'foo
	(format t "The inner catch returns ~s.~%"
		(catch 'foo
		    (unwind-protect (throw 'foo :first-throw)
			(throw 'foo :second-throw))))
	:outer-catch))

In my implementation, the THROW in the cleanup form of the
UNWIND-PROTECT happens when the inner CATCH (that is the target of the
first throw) is still in effect.  This means that the inner catch
returns :SECOND-THROW and the outer CATCH returns :OUTER-CATCH.  (This
is also the behavior exhibited by Lucid.)

However, under the proposal EXIT-EXTENT:MINIMAL, the dynamic extent of
the inner CATCH must end as soon as the first THROW begins.  Therefore
the target of the second THROW must be the outer CATCH.  According to
this proposal, the inner CATCH would never return and the outer one
must return :SECOND-THROW.  Right? 

This leads me to conclude that in spite of what the "Cost to
Implementors" section says, currently valid implementations *will* be
made invalid by this proposal, and that it would not be legitimate for
implementations to implement longer extents (as mentioned in the
"Esthetics" section).  Or am I still misunderstanding something?

-Sandra
-------