Re: defconst

[Luc Teirlinck]

(I forgot to include a CC to emacs-devel in a previous version of
this message.)

Richard Stallman wrote:
   
   Please don't suggest such major changes now.  Our goal now is to aim
   for a release.

In my message I very explicitly stated that I only suggested making
this change _after the release_.  I only wanted to know now whether
doing that was a possibility, in order to better know how to deal with
present defconst's.

       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.

   That is a drastic change, and I see no need for it.  Practically
   speaking, nothing disastrous happens if you change it with setq.

If the user changes a variable defined with defconst then the new
value can be overridden at any time without notice to the user.  That
is a dangerous situation and disastrous things _could_ happen,
depending on what variable is being played around with.

What about the following changes to lispref/variables.texi and the
docstring of `defconst' that add appropriate warnings about this
dangerous situation.

===File ~/variables.texi-diff===============================
*** variables.texi      19 Nov 2004 18:35:43 -0600      1.52
- --- variables.texi    19 Nov 2004 18:40:04 -0600      
***************
*** 415,423 ****
  a matter of intent, serving to inform human readers of whether the value
  should ever change.  Emacs Lisp does not restrict the ways in which a
  variable can be used based on @code{defconst} or @code{defvar}
! declarations.  However, it does make a difference for initialization:
! @code{defconst} unconditionally initializes the variable, while
! @code{defvar} initializes it only if it is void.
  
  @ignore
    One would expect user option variables to be defined with
- --- 415,431 ----
  a matter of intent, serving to inform human readers of whether the value
  should ever change.  Emacs Lisp does not restrict the ways in which a
  variable can be used based on @code{defconst} or @code{defvar}
! declarations (although it would be very inadvisable to change the
! value of a variable defined with @code{defconst}).  However, it does
! make a difference for initialization: @code{defconst} unconditionally
! initializes the variable, while @code{defvar} initializes it only if
! it is void.
! 
!   You should @strong{only} use @code{defconst} if you are absolutely
! sure that no user will ever want to change the value for any reason.
! If there is the slightest doubt about that, use @code{defvar}.
! Indeed, files can be loaded at unpredictable times and @code{defconst}
! would override the user's value behind his back.
  
  @ignore
    One would expect user option variables to be defined with
***************
*** 539,545 ****
  
  Here, @code{pi} is a constant that presumably ought not to be changed
  by anyone (attempts by the Indiana State Legislature notwithstanding).
! As the second form illustrates, however, this is only advisory.
  
  @example
  @group
- --- 547,555 ----
  
  Here, @code{pi} is a constant that presumably ought not to be changed
  by anyone (attempts by the Indiana State Legislature notwithstanding).
! As the second form illustrates, however, this is not enforced (but one
! should @emph{never} change the value of a variable defined by defconst
! regardless).
  
  @example
  @group
============================================================

===File ~/eval.c-diff=======================================
*** eval.c      06 Nov 2004 09:07:09 -0600      1.224
- --- eval.c    19 Nov 2004 19:12:17 -0600      
***************
*** 816,821 ****
- --- 816,828 ----
  If SYMBOL has a local binding, then this form sets the local binding's
  value.  However, you should normally not make local bindings for
  variables defined with this form.
+ 
+ It is very important to *only* use this form if you are *absolutely*
+ sure that no user will ever want to change the value for any reason.
+ If there is the slightest doubt about that, use `defvar'.  Indeed,
+ files can be loaded at unpredictable times and this form would
+ override the user's value behind his back.
+ 
  usage: (defconst SYMBOL INITVALUE [DOCSTRING])  */)
       (args)
       Lisp_Object args;
============================================================
------- End of forwarded message -------