EVALHOOK maintaining independent evaluation stacks

[Kent M Pitman <KMP @ MIT-MC>]

    Date: Thu, 6 Sep 84 22:36 EDT
    From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>

        Date: 6 September 1984 18:16-EDT
        From: Kent M Pitman <KMP @ MIT-MC>

        While I'm thinking about it ... There's a problem with EVALHOOK
        in that it really wants to pass a locative to the piece of code
        that's being EVAL'd. Consider the problem of a display-oriented
        stepper, trying to evaluate:
    	    (LAMBDA (X) (+ X X))
        ... If you think it's fair to assume that the lexically first X
        is the one that leads you there, consider:

    	    (LAMBDA (X Y) (COND ((FOO) X) (T (+ X Y))))

    I don't see why the user hook function can't maintain its own evaluation
    stack, back which it can look.  In general, of course, this requires it
    to understand special forms.  Your scheme, on the other hand, would require
    EVAL to be completely remodularized, since it does not currently receive
    the arguments it would need to compute the information you want in any
    system I know of.

In order to do this correctly, you must presuppose the complete semantics
of the interpreter. You might as well write your own DEBUG-EVAL which 
doesn't use EVAL at all. Part of the idea of EVALHOOK is to let EVAL do 
what it wants (handling hard cases, etc) and leave the relevant (and
incidentally much easier) stuff to the hook.

Without understanding making all these assumptions, an evaluation history
isn't going to tell you what X is being evaluated after the throw in:

	(BAR (*CATCH 'FOO (FOO (*THROW 'FOO NIL) X (FROB X))) X)

In order to know that, you'd have to know about the semantics of 
catch/throw in a relatively intimate way.

Similarly, you might get faked out by which X was being evaluated after
the call to EVAL in

	(PROGN (EVAL '(+ X 3)) X)

though APPLYHOOK might give you enough of a handle to get around this one.
I'm not sure. Page 322 of the CL manual suggests that APPLYHOOK wouldn't
help in the case of:

	(PROGN (MAPCAR #'EVAL '((+ X 3))) X)

By the way, it does not affect my argument that the two X's in question are
not in the same lexical contour. If anything, it strengthens the importance
of the argument.

Even in this example (from my last message), where we've just EVAL'd (FOO):

	(COND ((FOO) X Y)
	      (T X)),

you cannot which X is going to be evaluated without building into your
EVALHOOK an assumption about what COND does.

Does this help? I really believe that an explicit stack maintained by
EVALHOOK doesn't work, or that the work involved in coercing it work is at
least as great and probably more dangerous (in terms of being potentially
wrong) than that of just writing another evaluator. We tried that and it
fails in tricky code. Tricky code, by the way, is the sort of thing you
most need steppers to work on, I might add. In heavily macrofied code, you
can really get cases of throws out of arg positions, etc. that are
completely meaningful and I think not unreasonable to want to support.
-kmp