Re: Issue DEFCONSTANT-NOT-WIRED

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 7 Oct 88  14:19:38 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    > CLtL says that a change to a DEFPARAMETER'ed variable should be
    > considered a change to the program.  There are lots of other
    > situations where making a change to the program might cause situations
    > that "are an error", such as redefining a function as a macro.
    > Although CLtL does not explicitly allow or disallow it, some (many?)
    > implementations choose to issue warnings in such cases.  Therefore I
    > think it is legitimate both for users to use DEFPARAMETER for
    > situations where an error may result if the variable is changed, and
    > for implementations to be allowed (but not required) to issue warnings
    > about changing the values of DEFPARAMETER'ed variables.

    One might construe CLtL to mean that, but it is too big of an
    incompatible change from current practice to be seriously considered. 

Indeed. Since there's been mail following yours contesting this statement,
let me put in my two bits worth of reinforcement of this statement.

In my experience -- looking at quite a lot of Common Lisp code
by a number of authors -- people select between DEFPARAMETER and DEFVAR
primarily on the basis only of SETQ-IF-UNBOUND behavior.

I, and most other people I know, write DEFPARAMETER if re-loading the
same file should reset the value and DEFVAR otherwise. Consider:

 -----File A-----
 (DEFVAR *FOO* '())
 (DEFPARAMETER *BAR* '())
 ----------------

 -----File B-----
 (PUSH 'X *FOO*)
 (PUSH 'X *BAR*)
 ----------------

If you load A, then B, then A, you clobber *BAR*, but not *FOO*.
So I always DEFVAR things like lists of objects, etc. that act
as a database. But I always DEFPARAMETER things like global option
variables that would want to be re-initialized if the system was
re-loaded. Some people might not even DEFPARAMETER option variables,
figuring people who had set them would want their values retained.
But always, that decision is made on the basis of whether SETQ
or SETQ-IF-UNBOUND is done -- not on any mythical abstract useless
notion of what a "variable" vs "parameter" is.