Re: Working with constansts

[Pascal J. Bourguignon]

Nikolaj Schumacher <me@nschum.de> writes:

> 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.


Well, you shouldn't modify quoted literals either, since this is
modifying the program:

(defun f (x)
   (let ((y '(foo . bar)))
     (prog1 (car y)
        (setf (car y) x))))

(list (f 1) (f 2) (f 3) (symbol-function 'f)) 
--> (foo 1 2 (lambda (x) (let ((y (quote (3 . bar)))) (prog1 (car y) (setf (car 
y) x)))))



But what you say is correct, in the case of:

(defvar y (cons 'foo 'bar))
(defconst x y)


>>> 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

-- 
__Pascal Bourguignon__