[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

function specs


I do find FOO-INTERNAL-G0067 to be ridiculous.  My problem is that I
find (:INTERNAL 67 FOO) or whatever to be equally ridiculous, and
perhaps worse since it requires a whole new family of functions to
access these pseudo-names.

There is no problem in manipulating functions, since they are perfectly
good Lisp objects that can be passed around at will.  The problem with
TRACE and friends is that they cannot do their magic directly to a
function object (well, they could, but it would take an invisible pointer).
Instead, they need to interpose something between a function and
everyone who wants to get at it, and that requires knowing where other
code expects a function to be found.  To me, that still doesn't mean
that the place where a function conventionally lives is in any sense its
"name", except where that place happens to be the definition cell of a

One possible approach is to recognize that TRACE does not hack a function,
but rather a place where a function normally lives.  If we give TRACE a
symbol, it just hacks the definition cell.  Otherwise, the argument to
TRACE is a SETF-like expression that points to a place: property list,
entry in an array, or whatever.  That place must contain a function
object, and the encapsulated form is left there in place of the
original.  So (TRACE place) => (SETF place (TRACE-ENCAPSULATE place)).
To me, this seems much more natural than creating this new series of
"names" and a new family of function name hacking forms.

Similarly, if the "name" argument to DEFUN is not a symbol, it would
also be a SETF location:

(defun (get 'foo 'testing-function) ...)

In this case, the definition is an anonymous LAMBDA or the compiled form
thereof, and the DEFUN does the obvious SETF.  If the compiled
function-object wants to remember that it was being sent to some
particular location at the time of its DEFUN, so much the better; that
is useful info for the debugger, but it is not a name.

Maybe all we disagree about is whether to call the location expression a
name and whether to make up a whole new syntax for it, rather than using
the SETF syntax.

-- Scott