[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
*applyhook*
- To: Moon @ SCRC-RIVERSIDE
- Subject: *applyhook*
- From: Kent M Pitman <KMP @ MIT-MC>
- Date: Thu, 04 Oct 1984 20:37:00 -0000
- Cc: Common-Lisp @ SU-AI
- In-reply-to: Msg of Wed 26 Sep 84 23:05 EDT from Moon at SCRC-RIVERSIDE.ARPA
By the way, in talking to GSB on this issue, I have been convinced to withdraw
my objection to having the *APPLYHOOK* handler take the env argument of the
caller. After all, if the arguments being inspected have been passed incorrectly,
it would be handy to be able to compute new ones using the old environment.
I agree with most of your remarks regarding creating ways of accessing
parts of functions (name, env, params for sure; I'm not sure about body --
not clear to me exactly how that differs from interpreted to compiled
code). Also, in the case of env, it may be the case that either the meaning of
that will have to be left vague or else optimization may suffer. eg, hypothesizing
that ENV-OF accessed a closure's environment, would
(LAMBDA (Y) ((LAMBDA (X) (EQ X (EVAL 'X (ENV-OF #'(LAMBDA () X))))) Y))
and (LAMBDA (Y) (EQ Y (EVAL 'X (ENV-OF #'(LAMBDA () Y)))))
be semantically equivalent expressions? In light of this, how exactly would
you want the ENV-OF function to be used such that this sort of problem did
not come up?
-kmp