applyhook

[Moon@SCRC-RIVERSIDE.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
otherwise.

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.