A reply and some more thoughts on specializing built-in functions

[masinter.pa@Xerox.ARPA]

"I suppose we could allow a built-in function to be specialized with the
understanding that the change is not retroactive, but only applies to
user-level code compiled after the specialization is created."

This seems like a very bad idea, because it avoids the main "feature" of
CommonLoops, which is the ability to specialize functions "after the
fact".  

It would seem more reasonable to examine the book for those functions
which are natural candidates for specialization, and to discuss what
impact it might have to allow more specialization.

The cases that come to mind are:

(a) sequence functions. Currently, there are two kinds of sequences:
vector and list. Clearly, one simple application of
object-oriented-programming is the ability to define new kinds of
sequences. This is a fundamentally powerful feature in Smalltalk, for
example. Given that most sequence functions start out with a typecase,
this shouldn't be too burdensome, as long as the "built-in" methods
aren't redefinable (e.g., you can define (mapcar my-sequence) and
(mapcar zilch) but you can't redefine (mapcar list) or (mapcar vector)
and expect the system to work the same.

(b) arithmetic. Both an exciting and difficult, allowing new kinds of
objects in arithmetic expressions would allow for natural extensions to
dealing with element-wise array operations, continued fractions, and a
wide variety of other kinds of objects. Without allowing specialization
of the number primitives, one would have to do things like shadowing +
by a macro which expands into binary-add, with  

(defmethod binary-add ((x number) (y number)) (lisp:+ x y))

and then specializing binary-add instead. (This convolution is necessary
because lisp:+ isn't binary, but it only makes sense to add methods for
the binary version.)

(c) Generic recursive object operations. There are a number of generic
recursive object operations which should be specializable, with the rule
being that the operation applies itself to subparts, including EQUAL,
COPY, whatever happens underneath printing (so that the :print-function
option in defstruct really gets turned into a simple defmethod). I think
these correspond reasonably to the "super-general" functions that REM
was referring to in his last message to common-lisp@su-ai in a
discussion about how EQUAL might be "fixed" so that it descended into
structures.