Re: Working with constansts

[Nikolaj Schumacher]

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