NIL and DEFCONSTANT [Gall: Bug Report]

[Guy Steele <gls%AQUINAS.TMC@Think>]

Response to Fahlman:

    Response to Steele:

	Maybe a right attitude to take is that it is an error
	to execute any compiled code that refers to a DEFCONSTANT'ed
	name that has been re-DEFCONSTANT'ed to a different (non-EQL?)
	value since the code was compiled.

    Yeah, that seems reasonable.  We want to be able to change the value of
    a constant if, for example, we notice a typo, but once something has
    been compiled that uses that constant, it is unpredictable which value
    you get if you then change the constant.

	That would say that it is okay to (DEFCONSTANT T 43), but then
	you had better not execute any system code that refers to T.
	But the evaluator probably refers to T, so in practice you had
	simply better not do it.

    This looks like trouble to me.  I don't think we'd better tell the users
    that this is legal but that they'd probably better not do it in
    practice.  Unlike us high-powered language designers, mere users are
    likely to be confused by this.  Maybe we'd just better tell them that it
    is erroneous, wrongheaded, evil, and uncool to do this, and that if they
    persist in this practice Father Lisp won't bring them any parentheses
    when they hang out their bit buckets on Flag Day.

All I meant by this is that the evilness of redefining T follows logically
from (1) the proposed rule that allows users to carefully redefine things,
and (2) the fact that EVERYTHING depends on T.  What we tell the user is
another story.  An additional attitude is that it is reasonable for the
system to take a benevolent protective interest in those constants on which
it depends.  (Translation: refuse to change T because everything will break.)

--Guy