From: pjb@informatimago.com (Pascal J. Bourguignon)
To: help-gnu-emacs@gnu.org
Subject: Re: Working with constansts
Date: Tue, 12 May 2009 13:54:02 +0200 [thread overview]
Message-ID: <7ceiuuczad.fsf@pbourguignon.anevia.com> (raw)
In-Reply-To: mailman.7056.1242122790.31690.help-gnu-emacs@gnu.org
Nikolaj Schumacher <me@nschum.de> writes:
> pjb@informatimago.com (Pascal J. Bourguignon) wrote:
>
>> Richard Riley <rileyrgdev@googlemail.com> 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__
next prev parent reply other threads:[~2009-05-12 11:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-10 15:25 Working with constansts Decebal
2009-05-10 16:19 ` Pascal J. Bourguignon
2009-05-10 16:20 ` Richard Riley
2009-05-10 16:33 ` Pascal J. Bourguignon
2009-05-12 10:34 ` Nikolaj Schumacher
2009-05-10 17:02 ` Drew Adams
2009-05-10 17:28 ` Richard Riley
2009-05-11 7:39 ` Tassilo Horn
[not found] ` <mailman.6953.1241976532.31690.help-gnu-emacs@gnu.org>
2009-05-10 18:17 ` Pascal J. Bourguignon
2009-05-11 1:36 ` Richard Riley
2009-05-11 6:29 ` Pascal J. Bourguignon
2009-05-12 10:06 ` Nikolaj Schumacher
[not found] ` <mailman.7056.1242122790.31690.help-gnu-emacs@gnu.org>
2009-05-12 11:54 ` Pascal J. Bourguignon [this message]
2009-05-18 10:55 ` Nikolaj Schumacher
[not found] ` <7ceiuuczad.fsf@pbourguignon.informatimago.com>
[not found] ` <mailman.7379.1242644154.31690.help-gnu-emacs@gnu.org>
2009-05-18 12:20 ` Pascal J. Bourguignon
2009-05-18 19:19 ` Nikolaj Schumacher
2009-05-10 18:59 ` Barry Margolin
2009-05-11 1:38 ` Richard Riley
2009-05-12 9:44 ` Nikolaj Schumacher
[not found] ` <mailman.7052.1242121473.31690.help-gnu-emacs@gnu.org>
2009-05-12 11:43 ` Pascal J. Bourguignon
2009-05-13 4:59 ` Barry Margolin
2009-05-13 13:41 ` Ralf Wachinger
2009-05-13 21:23 ` Barry Margolin
2009-05-11 9:58 ` Thien-Thi Nguyen
[not found] ` <mailman.6988.1242036217.31690.help-gnu-emacs@gnu.org>
2009-05-12 1:31 ` Barry Margolin
2009-05-11 8:27 ` Decebal
2009-05-12 9:46 ` Nikolaj Schumacher
2009-05-10 16:31 ` Drew Adams
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=7ceiuuczad.fsf@pbourguignon.anevia.com \
--to=pjb@informatimago.com \
--cc=help-gnu-emacs@gnu.org \
/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.