From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: pjb@informatimago.com (Pascal J. Bourguignon) Newsgroups: gmane.emacs.help Subject: Re: Working with constansts Date: Tue, 12 May 2009 13:54:02 +0200 Organization: Anevia SAS Message-ID: <7ceiuuczad.fsf@pbourguignon.anevia.com> References: <87d4ahylp3.fsf@galatea.local> <000801c9d191$22a21340$0200a8c0@us.oracle.com> <874ovszuu3.fsf@galatea.local> <87zldkxicx.fsf@galatea.local> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242132585 10756 80.91.229.12 (12 May 2009 12:49:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 May 2009 12:49:45 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue May 12 14:49:36 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 1M3rQ2-0000cu-F5 for geh-help-gnu-emacs@m.gmane.org; Tue, 12 May 2009 14:49:14 +0200 Original-Received: from localhost ([127.0.0.1]:56968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3rQ1-0002Ez-TH for geh-help-gnu-emacs@m.gmane.org; Tue, 12 May 2009 08:49:13 -0400 Original-Path: news.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!cleanfeed4-a.proxad.net!nnrp3-2.free.fr!not-for-mail Original-Newsgroups: gnu.emacs.help Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/22.2 (gnu/linux) Cancel-Lock: sha1:MzQwYTVjYmM1ZTdkNDlkMjU1YTIwZTJkMWU2MDhlZGFlYzE5NDdiZA== Original-Lines: 126 Original-NNTP-Posting-Date: 12 May 2009 13:54:02 MEST Original-NNTP-Posting-Host: 88.170.236.224 Original-X-Trace: 1242129242 news-2.free.fr 15981 88.170.236.224:59551 Original-X-Complaints-To: abuse@proxad.net Original-Xref: news.stanford.edu gnu.emacs.help:169116 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:64378 Archived-At: Nikolaj Schumacher writes: > pjb@informatimago.com (Pascal J. Bourguignon) wrote: > >> Richard Riley writes: >> >>> Of course I understand if the answer is "history and that's the way it >>> is" but I would sympathise with a new programmer to Lisp that is >>> surprised he can modify a "const" especially if he came from a C/C++ >>> background where we all fully understand WHY consts are useful for the >>> programmer but the compiler also enforced it. >> >> The important point is that a lisp system is being programmed at the >> same time it is executed. Therefore redefining a constant may be >> taken into account, because it may be what the _programmer_ really >> means. >> >> In C, you would have to recompile the program before a change to a >> constant is taken into account, but it would be very possible to >> modify a constant: nothing prevents you to edit the C sources, >> recompile and relaunch. > > Certainly const in C doesn't mean the value is determined at compile > time. It just means: "This variable shouldn't be modified after its > initialization." > > 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. Changing the value stored in the const variable won't archieve much. The same may occur in Common Lisp. -*- mode: compilation; default-directory: "~/src/tests-c++/" -*- Compilation started at Tue May 12 13:46:08 $ gcc -O3 -S -o constant.s constant.c ; cat constant.c ; echo ------------------- ; cat constant.s const int c=42; int f(int x){ return c+x; } ------------------- .file "constant.c" .text .p2align 4,,15 .globl f .type f, @function f: .LFB2: leal 42(%rdi), %eax -------- first copy of the constant ret .LFE2: .size f, .-f .globl c .section .rodata .align 4 .type c, @object .size c, 4 c: .long 42 --------- second copy of the constant .section .eh_frame,"a",@progbits .Lframe1: .long .LECIE1-.LSCIE1 .LSCIE1: .long 0x0 .byte 0x1 .string "zR" .uleb128 0x1 .sleb128 -8 .byte 0x10 .uleb128 0x1 .byte 0x3 .byte 0xc .uleb128 0x7 .uleb128 0x8 .byte 0x90 .uleb128 0x1 .align 8 .LECIE1: .LSFDE1: .long .LEFDE1-.LASFDE1 .LASFDE1: .long .LASFDE1-.Lframe1 .long .LFB2 .long .LFE2-.LFB2 .uleb128 0x0 .align 8 .LEFDE1: .ident "GCC: (Gentoo 4.3.3-r1 p1.1, pie-10.1.5) 4.3.3" .section .note.GNU-stack,"",@progbits Compilation finished at Tue May 12 13:46:08 > 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. > It does one thing, though: > > (setq xxx 'user) > (defvar xxx 'library) > xxx => 'user > > (setq xxx 'user) > (defconst xxx 'library) > xxx => 'library > > A tiny step towards enforcing the value. > > > regards, > Nikolaj Schumacher -- __Pascal Bourguignon__