defconst

[Luc Teirlinck]

I wonder what the exact usefulness of defconst, in its present form,
is.  It does two things, one very concrete, the other rather vague
(and therefore not very useful).

The concrete effect of `(defconst var value)' is that it is equivalent
with `(defvar var value)' followed by `(setq var value)', that is, its
concrete effect is that of the CL function `defparameter'.

Apart from that, quoted from `(elisp)Defining Variables':

     This special form defines SYMBOL as a value and initializes it.
     It informs a person reading your code that SYMBOL has a standard
     global value, established here, that should not be changed by the
     user or by other programs.

There are two problems with this.

Firstly, it does not inform everybody that needs to be informed.  It
informs the person reading the defconst directly, and the person
writing Elisp code, _who compiles and pays attention to compiler
warnings_, through a compiler warning.  It does not inform the user
who changes the value in his .emacs or interactively that he is doing
something that may have adverse consequences.  It does not inform the
`C-h v' user.

Secondly, one can not rely on what the information concretely means.
Many people use defconst just because they do not consider it _very
likely_ that somebody might want to change the value of the variable.

I believe it would be better if `defconst' behaved like `defconstant'
in CLISP: throw an error if the user or a program tries to change the
value through anything else but a second defconst.  If a second
defconst resets the "constant" to a different value, give a warning,
but change the constant's value anyway.  Do not warn about a defconst
that keeps the value the same.  (Note that this is CLISP specific
behavior.  CL leaves most of the `defconstant' behavior up to the
implementation.)

This way, everybody who tries to change the value gets informed of the
fact that it might cause trouble and still gets the chance to do it
anyway (but knowing the risk).  It would allow programmers seeing a
defconst to rely on the fact that the value they see in the defconst
is the value they will get if they evaluate the symbol.  Currently,
they can not do that.  `defconst' would produce something `read-only'
which it currently does not.

Maybe it might not be advisable to make such a change before the
release, but what about after it?  I bring it up now, because a
decision on this might affect what we do with current defconst's.

Sincerely,

Luc.








 LocalWords:  defconst's