[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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?