Re: Working with constansts

[pjb@informatimago.com (Pascal J. Bourguignon)]

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__