From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: defconst Date: 19 Nov 2004 19:25:36 -0600 Message-ID: <200411200151.iAK1pHf18782@raven.dms.auburn.edu> References: NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1100916582 19348 80.91.229.6 (20 Nov 2004 02:09:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 20 Nov 2004 02:09:42 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 20 03:09:19 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CVKgg-0000gK-00 for ; Sat, 20 Nov 2004 03:09:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CVKZd-0004r2-GG for ged-emacs-devel@m.gmane.org; Fri, 19 Nov 2004 21:02:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CVKZV-0004qu-GG for emacs-devel@gnu.org; Fri, 19 Nov 2004 21:01:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CVKZU-0004qg-SL for emacs-devel@gnu.org; Fri, 19 Nov 2004 21:01:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CVKZU-0004qZ-JG for emacs-devel@gnu.org; Fri, 19 Nov 2004 21:01:52 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CVKQI-000078-Hi for emacs-devel@gnu.org; Fri, 19 Nov 2004 20:52:26 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id iAK1qHFu001697 for ; Fri, 19 Nov 2004 19:52:17 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id iAK1pHf18782; Fri, 19 Nov 2004 19:51:17 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: emacs-devel@gnu.org In-reply-to: (message from Richard Stallman on Thu, 18 Nov 2004 21:25:38 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:30115 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30115 (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 -------