Date: Fri, 20 Mar 1992 12:57 CST
From: ·······@kepler.arc.nasa.gov (Andrew Philpot)
[Philpot notes that the new Allegro release complains when you try
to define a class named VARIABLE and asks if the behavior is
correct.]
The rational in the cleanup issue LISP-SYMBOL-REDEFINITION, the
resolution of which forbids associating most (if not all) kinds of
global definitions with symbols exported from the COMMON-LISP package,
is:
"This proposal is the only simple resolution of the problem
description that we can imagine that is consistent with current
implementation techniques.
"Allowing arbitrary redefinition of symbols in the system would
place severe restrictions on implementations not to actually use
those symbols in macro expansions of other symbols, in function
calls, etc. While some looser restrictions might do for any
particular Common Lisp implementation, there seems to be no good way
to distinguish between those symbols that are redefinable and those
that are not.
"In general, programs can redefine functions safely by creating new
symbols in their own package, possibly shadowing the name."
Also, you can argue that associating a global definition with a symbol
defined by the standard is bad in a multi-module environment. One
module could easily stomp over another's definition, causing all kinds
of hard-to-track-down bugs.
Of course, the "solution" is to shadow the symbol in my package. I
just can't help wondering how much existing code this decision will
break (has broken). I did notice that the new DEFINE-DECLARATIONS
macro made a wiser choice, using the keyword symbol :VARIABLE for a
similar purpose.
Comments? Clarification? Discussion?
It does seem pretty lame that such a piddling usage of the symbol
VARIABLE in the standard prevents users from giving global definitions
to it. A lot of the "good" symbols are already taken. I had lots of
code break because of this issue. On the other hand, the rational makes
some sense, and, in order to write portable Common Lisp code in these
days of shifting standards, a lot of folks probably already have package
setups that make defining one more shadowing symbol a small amount of
work.
--David Gadbois