[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working with constansts
From: |
Pascal J. Bourguignon |
Subject: |
Re: Working with constansts |
Date: |
Mon, 18 May 2009 14:20:50 +0200 |
User-agent: |
Gnus/5.101 (Gnus v5.10.10) Emacs/22.2 (gnu/linux) |
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__
- Re: Working with constansts, (continued)
- Message not available
- Re: Working with constansts, Pascal J. Bourguignon, 2009/05/10
- Re: Working with constansts, Richard Riley, 2009/05/10
- Re: Working with constansts, Pascal J. Bourguignon, 2009/05/11
- Re: Working with constansts, Nikolaj Schumacher, 2009/05/12
- Message not available
- Re: Working with constansts, Pascal J. Bourguignon, 2009/05/12
- Re: Working with constansts, Nikolaj Schumacher, 2009/05/18
- Message not available
- Message not available
- Message not available
- Re: Working with constansts,
Pascal J. Bourguignon <=
- Re: Working with constansts, Nikolaj Schumacher, 2009/05/18
- Message not available
- Re: Working with constansts, Barry Margolin, 2009/05/10
- Re: Working with constansts, Richard Riley, 2009/05/10
- Re: Working with constansts, Nikolaj Schumacher, 2009/05/12
- Message not available
- Re: Working with constansts, Pascal J. Bourguignon, 2009/05/12
- Message not available
- Re: Working with constansts, Barry Margolin, 2009/05/13
- Re: Working with constansts, Ralf Wachinger, 2009/05/13
- Re: Working with constansts, Barry Margolin, 2009/05/13
- Re: Working with constansts, Thien-Thi Nguyen, 2009/05/11
- Message not available
- Re: Working with constansts, Barry Margolin, 2009/05/11