Re: Issue DEFCONSTANT-NOT-WIRED

[Brad Miller <miller@CS.ROCHESTER.EDU>]

    Date: Fri, 7 Oct 88 18:08:23 pdt
    From: Eric Benson <eb@lucid.com>

    Perhaps.  Do you consider this "a change *to* the program" as stated
    in CLtL?  If you only ever change it at the top level, for example,
    you're probably working in the spirit of DEFPARAMETER.  Would you need
    to change your program to use DEFVAR instead of DEFPARAMETER if a
    warning was signalled every time a variable defined with DEFPARAMETER
    is SETQed (as opposed to re-evaluating the DEFPARAMETER form with a
    different initial value)?

I have no problem with getting a warning; if I change it, it is usually in a
patch file (where such warnings are turned off anyway). I am just concerned
about making a semantic difference between having the compiler assume that a
defparameter will never change but not folding, vs. assuming it may change,
but not during execution. The model that essentially folds defparameter into
a special kind of defvar, for example, works. Making it any kind of
defconstant probably doesn't. Consider when the type of the the
defparameter changes, for example. If the compiler doesn't fold the
reference but does assume that the reference doesn't change, it may make
assumptions about the type of the object that aren't going to be valid
across (what I have been assuming are) valid redefinitions of the parameter.

----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}