A reply and some more thoughts on specializing built-in

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

I think we had better be careful to separate this business of
specializing built-in functions from the rest of the CommonLoops
proposal.  The CommonLoops proposal so far is almost entirely an add-on
to Common Lisp; anything that requires a significant rewrite of existing
implementations is going to meet with much more determined resistance,
and if it slows down vanilla Lisp programs, there is absolutely no hope
of its being accepted.  I would hate to scare people away from the rest
of the CommonLoops proposal just because they are afraid of where this
tinkering with the guts of Common Lisp might lead.

The one safe case is where a built-in function handles different
argument-types in different ways (and therefore requires a type test)
and where the method extends (not "specializes") the function to handle
argument types that otherwise would signal an error.  Such cases can be
handled entirely in the error handler (once we get an error system
specified) or by adding one extra hook to the run-time type-dispatch.
If we are careful, we could add this without disrupting anything.

Similarly, it might be safe to do what I suggested before: allow users
to specialize built-in functions with the clear understanding that the
specialization is not retroactive.  Users could screw themselves by
specializing + or CDR and therefore making them horribly slow from that
time on, but no system code would be affected.

But as soon as you start talking about RETROACTIVE SPECIALIZATION of
built-in functions, that is a much more serious business.  I think that
we must avoid this.  If necessary, we might introduce a new set of
generic functions that are clones of the built-in functions, but are
specializable.  We could put all of these in a package named something
like PSEUDO, and we could then re-use the old familiar names.  So
LISP:EQUAL would behave as it always has, but PSEUDO:EQUAL would be a
specializable version whose default behavior is to do what EQUAL does,
but which the user could bend beyond all recognition if he wants to.

-- Scott