[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Postmaster at SCRC-STONY-BROOK: Unable to deliver letter]
- To: Common-Lisp@SU-AI.ARPA
- Subject: [Postmaster at SCRC-STONY-BROOK: Unable to deliver letter]
- From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
- Date: Mon, 10 Sep 84 14:35 EDT
No one but KMP saw this message the first time, which may have made
for a mysterious-looking conversation. Hopefully it will go through
Date: Thu, 6 Sep 84 22:36 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: More (unrelated) EVALHOOK issues
To: Kent M Pitman <KMP@MIT-DM.ARPA>
In-Reply-To: The message of 6 Sep 84 18:16-EDT from Kent M Pitman <KMP at MIT-MC>
Date: 6 September 1984 18:16-EDT
From: Kent M Pitman <KMP @ MIT-MC>
While I'm thinking about it (something I should have brought up ages ago,
but it might as well at least be on the books)...
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))
when EVALHOOK traps on evaluating X, how can you know which X you are
evaluating so as to highlight it. 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))))
It would have been nice if we had made it so the form passed in was a
list whose CAR was the form to be evaluated rather than the form itself.
That way, in the first example above, EVALHOOK could see
and in the second, (X). Or perhaps that could be passed in as an extra
arg, being NIL when there was no locative available.
This shortcoming in the info provided by EVALHOOK has come up in
several stepper projects at MIT, and I should have mentioned it before,
but it should be thought about when time for revisions comes along.
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.