Re: SETF- method names

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.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.

    A this would solve the problem nicely, for those cases where the
    funcallable object is well defined (fundefs, generic functions,
    symbols w. function cell bound, methods, etc.). 

    The problem remains with SETF forms which take generalized variable
    references, like SVREF, since there is currently no way to obtain
    the funcallable object corresponding to the SETF "method" (to use
    CLtL terminology). 

You actually mean the funcallable object called by the form that is
returned by the SETF "method"; those type of SETF-"methods" are macros,
unlike CLOS setf-methods, which are functions.

Yes, this is a problem and I don't know of any good answers to it; after
all, the SETF form might well expand into a call to a different function
depending on seemingly minor variations in details of the arguments.
Not a problem for CLOS, just a problem for CL.  Your technique of
macroexpanding a sample form and assuming that the function that appears
there is the one that is going to be called is probably as good as any.