redefining Common Lisp functions

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 11 Apr 87 14:44:52 PST
    From: masinter.PA@Xerox.COM

    Rather than attempting to divine meaning in CLtL, lets focus on some
    related but different questions:

    1. (Current practice) In your favorite Common Lisp implementation, which
    of the predefined Common Lisp functions, macros, and special forms can
    be safely redefined without causing unpredictable behavior somewhere
    else in the system? 

I don't know what "safely" means; I made an assumption about what you meant
such that the answer is "none of them, not only in my favorite implementation,
but in all the others too."

    2. (Future standards) Which of the predefined Common Lisp functions,
    macros, and special forms do you think *should* be redefinable.

I don't believe that Common Lisp should define the meaning of redefining
any of the predefined functions.  Thus I believe that it should "be an error"
to redefine any predefined function.  JonL's point about the difference between
truly redefining something and merely encapsulating it (e.g. for TRACE) is
relevant here.  But note that I do not believe that Common Lisp should require
compiled code that appears to call a predefined function, macro, or special
form to be necessarily affected by any encapsulation of that functionoid.

    3. (More constrained redefining) Presuming the CLOS, which of the
    predefined Common Lisp functions should be specializable for
    user-defined classes? How should such specialization affect the rest of
    the behavior of Common Lisp?

The working group for defining the proposed object-oriented programming
standard ("CLOS") has thought about this just enough to realize that it
is complex and difficult.  The group, or someone, will have to do more
work in this area, but it's not going to be easy.