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

[gls@Think.COM]

I think Moon has been put off by the word "continuation", and perhaps
rightly so.  Let me appeal to yet another model.

Unwinding is not an atomic process, because UNWIND-PROTECT allows arbitrary
user code to step in and execute in the middle of an unwinding.  How can we
characterize the state of the computation when that user code is running?
In what ways can the user code examine, or even alter, that state?

It may help to consider the PDP-10 instruction set.  BLT is not an atomic
operation, but rather an interruptible one.  Therefore its interface was
carefully arranged so that its intermediate state could be easily
summarized.  This intermediate state was part of the advertised interface
to the user.  While I think very few programs actually checked this
intermediate state, or tried to alter it in mid-BLT, in principle it
was possible.

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*.  As I
recall, this was trivial under ITS, as the state was accessible to the user
program, but very difficult under TENEX, as the relevant state was not
accessible: the only way to get rid of the state "you're in an interrupt
handler" was to return to the very PC where you took the interrupt, and no
other, and this was a real pain.  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, but then
there must be some explanation of how that state information is remembered,
how it interacts with other control actions over time, and whether it
can be queried.

--Guy