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

[gls@Think.COM]

   Date: Thu, 2 Jun 88 21:14:52 PDT
   From: Jon L White <edsel!jonl@labrea.stanford.edu>

   re: Conversely, consider the INTPRO (interrupt protect) macros we used in the
       source code of PDP-10 MacLisp.  The problem here was that it was essential
       that certain crucial instruction sequences be regarded as atomic (such as
       the guts of CONS), and yet there was a provision for running arbitrary user
       code during an interrupt.  The game here was that the interrupt trap
       handler checked the PC, and if the PC was in a crucial interval then some
       cleanup routine was performed, and *the interrupt state was then modified
       to return to a PC other than where the interrupt had occurred*. . . . 
	I think this situation is very similar to
       an UNWIND-PROTECT taking a look at the state of a Lisp data structure,
       discovering that it is inconsistent, and deciding to THROW elsewhere
       instead.  Now maybe a previous THROW should not be forgotten, . . . 

   I believe the analogy you are making here supports the notion of "extending"
   the throw, but not one of "barricading" it; it worst, it would "extend"
   the PC to a point a little beyond where the interrupt really happend.
   It was like retroactively masking out interrupts during the interval
   between the two PC's.

   To the extent that this analogy has any relevance at all for the CL dynamic 
   scoping problem, then one should note that the "cleanup" routine for the 
   INTPRO hack was completely "dynamically" scoped;  that is, it is like 
   "Situation 0" of the the proposal under discussion, rather than the 
   disputed "Situation 1".



   -- JonL --

Indeed.  I am more sympathetic to the "THROW commits" notion after
further pondering this analogy.  My main point is that the nature of
the intermediate state needs to be made clear.

--Guy