all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: Rob Riepel <riepel@networking.stanford.edu>,
	Michael Kifer <kifer@cs.stonybrook.edu>,
	Kyle Jones <kyleuunet.uu.net@raven.dms.auburn.edu>
Subject: defconst
Date: Sun, 14 Nov 2004 12:33:47 -0600 (CST)	[thread overview]
Message-ID: <200411141833.iAEIXlg24233@raven.dms.auburn.edu> (raw)

I believe that `defconst' is a relatively widely misused function.  I
believe that it should only be used for something that is an absolute
constant.  Yet people seem to use it for such things as variables that
should only be changed by the user but not by Lisp code, or vice-versa,
or variables that have no effect when changed with setq (but only if a
function is called), and any other of a number of situations where
changing the value of a variable has to be done carefully, or only in
certain situations.

Using `defconst' instead of `defvar' is much more than just a
stylistic error.  If the file gets reloaded, then the defconst, unlike
defvar, will override any changes made thus far in the Elisp session,
behind the user's back.  This can be very confusing to the user.
Thus, it should only be used if _any_ change to the variable in any
way would be wrong.  If in doubt, I believe one should always use defvar.

Maybe `defconst' is OK for version numbers.  They are not necessarily
constants, but if a new version of a package is loaded, the old
version number should indeed be overridden.

I only will handle uses of defconst that produced compiler warnings.
I am afraid that the problem is more widespread.

Compiler warnings are produced by defconsts in the viper package,
cust-print.el, tpu-edt.el, life.el and lao.el.

It appears that the vast majority of the many defconsts in the viper
package should be defvar's.  I hope that the author of viper.el still
maintains the package and can take a look at this.

For the four other files, I will propose concrete changes.

I CC-ed the authors of the viper, tpu-edt and life packages. 


Sincerely,

Luc.

             reply	other threads:[~2004-11-14 18:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-14 18:33 Luc Teirlinck [this message]
2004-11-15 14:00 ` defconst Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2004-11-18  0:21 defconst Luc Teirlinck
2004-11-18  0:36 ` defconst Drew Adams
2004-11-18  1:17 ` defconst Stefan
2004-11-19  2:25 ` defconst Richard Stallman
2004-11-20  1:25   ` defconst Luc Teirlinck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200411141833.iAEIXlg24233@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=kifer@cs.stonybrook.edu \
    --cc=kyleuunet.uu.net@raven.dms.auburn.edu \
    --cc=riepel@networking.stanford.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.