[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Common-Lisp@SU-AI.ARPA
- Subject: applyhook
- From: Moon@SCRC-RIVERSIDE.ARPA
- Date: Wed, 26 Sep 84 23:05 EDT
- In-reply-to: <840831202452.2.MOON@EUPHRATES.SCRC.Symbolics>, The message of 7 Sep 84 19:00-EDT from WVANROGGEN at DEC-MARLBORO, The message of 10 Sep 84 03:24-EDT from GSB at MIT-MC
- Redistributed-date: Thu, 4 Oct 84 15:25 EDT
- Redistributed-date: Sun, 30 Sep 84 22:14 EDT
- Redistributed-to: Common-Lisp@SU-AI.ARPA
- Redistributed-to: Common-Lisp@SU-AI.ARPA
Date: Fri, 31 Aug 84 20:24 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
APPLYHOOK should not take an &OPTIONAL ENV argument.
Similarly *APPLYHOOK* should receive two arguments, not three arguments.
An environment is not meaningful for the APPLY operation, only for the EVAL operation.
Does anyone disagree?
I won't bother everyone by including the whole conversation that resulted from this,
just the final messages.
Date: Fri 7 Sep 84 19:00:15-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Actually, I hadn't thought about the potential ambiguity of which
environment would be passed to the apply hook function; I had just
assumed that it would be the same as that passed to the eval hook
function immediately before.
It seems to me that the purpose of applyhook is to allow one to
examine the actual function and the actual arguments it's about to
be applied to. (I suppose you could get the effect of the applyhook
by using the evalhook and simulating the evaluator--but that's what
this mechanism should help avoid.) It's a lot easier to examine
the environment of the function when it is handed to you. On the other
hand you could argue that any debugging facility will always use both
evalhook and applyhook simultaneously, but that shouldn't be necessary.
Date: 10 September 1984 03:24-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
I think we've safely established that in order to just function
properly, APPLYHOOK (and therefore the value of *APPLYHOOK*) does
not need to be given an environment argument.
As someone said, it makes no sense to pass one environment because
there are two involved. To me, that means we should pass BOTH
environments. After all, one of the purposes of having this is for
debugging, from user code. If we did not want this we wouldn't have
defined the hooks, just specified the existence of STEP like we have
TRACE. *APPLYHOOK* should be given TWO environments: one is the
current environment (as of when the hook is invoked -- like that given
to *evalhook*). The other is an environment object gleaned from the
function being applied. This is so that *applyhook* can examine
either one. Possibly in the case of compiled or globally defined
functions, the function-environment argument will be NIL, of course.
So, what i propose is this:
*APPLYHOOK* gets called on 4 arguments:
(1) the function being applied
(2) the list of arguments
(3) the environment of the function
(4) the current environment.
APPLYHOOK takes only arguments of the function, arguments, evalhookfn,
and applyhookfn. No environment argument at all -- the function
carries the environment with it. Evaluation of a lambda combination
((lambda ...) ...) passes a function made (as if) by evaluating
(function (lambda ...)).
The function-environment argument to *applyhook* is deliberately
redundant with the environment carried by the function, so that it may
be an environment object just like the current-environment argument,
and thus examined/whatever similarly.
I feel fairly strongly that to not pass these environments to
*applyhook* just because it looks now like we can get away with it
will unnecessarily restrict any sort of debugging extensions in the
future. And even within the present CL definition user code can do
things with them by passing them to EVAL.
This is probably right. Certainly you all talked me into believing the theory
that *applyhook* should be passed the environment in which the arguments
were evaluated, since some programs might need that and it's not easily accessible
As for whether the *applyhook* should also receive the environment in which forms
in the body of the function will be evaluated, my feeling is: maybe, but wouldn't
it be better to provide general facilities for accessing the various parts of
a function (that is, an applicable object; that is, anything that can be the
first argument to *applyhook* and also anything that can be the result of
SYMBOL-FUNCTION). These parts include at least the name, the environment, the
parameter list, and the body.
For now, in my system, I decided to compromise and implement what it says in the
manual (always a good default!). *applyhook* takes three arguments and
applyhook takes five arguments (one of which is optional). As for what the
manual doesn't say, the last argument to *applyhook* is the environment in which
the arguments were evaluated, the last argument to applyhook is ignored.
- From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>