[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NIL and DEFCONSTANT [Gall: Bug Report]
- To: common-lisp@SU-AI.ARPA
- Subject: NIL and DEFCONSTANT [Gall: Bug Report]
- From: Guy Steele <gls%AQUINAS.TMC@Think>
- Date: Tue, 9 Apr 85 10:09 EST
- Cc: gls%AQUINAS.TMC@Think
- In-reply-to: <FAHLMAN.12101655193.BABYL@CMU-CS-C.ARPA>
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.)