From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nikolaj Schumacher Newsgroups: gmane.emacs.help Subject: Re: Working with constansts Date: Mon, 18 May 2009 12:55:50 +0200 Message-ID: References: <87d4ahylp3.fsf@galatea.local> <000801c9d191$22a21340$0200a8c0@us.oracle.com> <874ovszuu3.fsf@galatea.local> <87zldkxicx.fsf@galatea.local> <7ceiuuczad.fsf@pbourguignon.anevia.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242644186 24073 80.91.229.12 (18 May 2009 10:56:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 May 2009 10:56:26 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: pjb@informatimago.com (Pascal J. Bourguignon) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 18 12:56:19 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M60W2-0005ny-Hp for geh-help-gnu-emacs@m.gmane.org; Mon, 18 May 2009 12:56:19 +0200 Original-Received: from localhost ([127.0.0.1]:38410 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M60W1-0000TV-Vn for geh-help-gnu-emacs@m.gmane.org; Mon, 18 May 2009 06:56:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M60Ve-0000RP-1j for help-gnu-emacs@gnu.org; Mon, 18 May 2009 06:55:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M60Vd-0000Qi-AV for help-gnu-emacs@gnu.org; Mon, 18 May 2009 06:55:53 -0400 Original-Received: from [199.232.76.173] (port=50526 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M60Vd-0000QM-5C for help-gnu-emacs@gnu.org; Mon, 18 May 2009 06:55:53 -0400 Original-Received: from dd18200.kasserver.com ([85.13.138.168]:33589) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M60Vc-0005Yf-M4 for help-gnu-emacs@gnu.org; Mon, 18 May 2009 06:55:52 -0400 Original-Received: from thursday (e176228187.adsl.alicedsl.de [85.176.228.187]) by dd18200.kasserver.com (Postfix) with ESMTP id B707F1861BA2F; Mon, 18 May 2009 12:55:54 +0200 (CEST) In-Reply-To: <7ceiuuczad.fsf@pbourguignon.anevia.com> (Pascal J. Bourguignon's message of "Tue, 12 May 2009 13:54:02 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (darwin) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:64531 Archived-At: pjb@informatimago.com (Pascal J. Bourguignon) wrote: >> And in fact, you can cast constness away in C++, so it really has >> nothing to do with execution versus compile time. It's just a helper >> for the developer to prevent side-effects. > > However, the C or C++ compilers are allowed to consider that the value > of the constant won't change, so they may inline any number of copies > they want. Yes, I was thinking of const references... And in lisp, consts would actually be references (maybe with the exception of numbers) (defconst x '(foo . bar) We've talked about (setq x 'foo) being illegal, but that would not prevent (setcar x 'bar). And even if you prevent that, you can have: (defvar y '(foo . bar) (defconst x y) Now the compiler cannot assume that y will not change, it's just a reminder to the developer. >> There really is no pressing requirement for the current behavior, the >> run-time just doesn't verify it. > > Nothing would prevent emacs lisp to specify defconst in such a way the > byte compiler could do the same. Only in the case of emacs it's more > practical to change the value of the constant, because it means that > you can modify your program without having to restart emacs, which is > a good thing in the case of an editor/IDE/OS. And nothing would prevent the byte-compiler (and eval-last-sexp) to have special privileges for overriding consts in a live environment. (You don't have to format a disk to reclaim write-protected files, either.) Certainly, inconsistencies might appear, unless every function inlining the value is also re-evaluated. But that's also the case with macros. regards, Nikolaj Schumacher