Re: SETF- method names

[Jim Kempf <kempf%hplabsc@hplabs.HP.COM>]

>    Date: Thu, 11 Jun 87 07:45:01 pdt
>    From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
>
>    >2) With generic functions, there is such a level of indirection without
>    >using a name, namely the generic function object.  If TRACE were a
>    >generic function that had an implementation dependent method on
>    >GENERIC-FUNCTION, it would wqork fine.  So again no names are needed. 
>    >
>
>Actually this opens its own can of worms.  I can't figure out from CLtL
>whether TRACE is intended to be an operation on function names, or on
>functions.  Perhaps it is intentionally left to the discretion of the
>particular programming environment.  All I know is that in Maclisp and
>Zetalisp it was defined to be an operation on function names; but making
>it operate on generic-function and method objects would make it an
>operation on functions.  Here's an example to show what I mean by the
>distinction:
>
>(defun foo (x) (print x))
>(let ((f (function foo)))
>  (trace foo)
>  (funcall f 105))
>
>If TRACE is an operation on function names, this just prints 105.  If it's
>an operation on functions, it generates tracing output as well.
>

True, it could complicate implementations. The typical way of dealing
with tracing via names is to wrap the fundef with a wrapper function,
and hang the wrapper off the symbol's function cell. This doesn't demand
anything special of the fundef or symbol, since symbols are typically
writable. If TRACE becomes an operation on fundefs, it's got to modify
the fundef object, perhaps (extrapolating from the implementation
I'm aware of) putting a jump to the trace function as the first instruction
in the fundef. This may get difficult, if fundefs are in restricted
parts of memory, like nonwritable, which often is used for sharing
executable code between processes in different address spaces (again,
in the implementation I know best).


			jak