applyhook and environments

[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.