[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
redefining Common Lisp functions
Date: 11 Apr 87 14:44:52 PST
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.