GNU bug report logs - #40671
[DOC] modify literal objects

Previous Next

Full log

Message #360 received at 40671 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Drew Adams <drew.adams <at> oracle.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
 Mattias Engdegård <mattiase <at> acm.org>, 40671 <at> debbugs.gnu.org,
 Richard Stallman <rms <at> gnu.org>, ke.vigouroux <at> laposte.net
Subject: Re: bug#40671: [DOC] modify literal objects
Date: Sun, 3 May 2020 04:30:37 +0300

On 02.05.2020 22:35, Paul Eggert wrote:

>> The "objects that appear as a constant" are objects to which exist references
>> from executable code, and where such references are "constant" (or possibly
>> constant, since an implementation might opt not to coalesce the values). That
>> why it's about constant references (and objects to which such references exist).
> 
> I don't understand this point.
> 
> It sounds like you might be trying to distinguish between constant references
> (i.e., pointers that don't change) and constant objects implemented via
> references (i.e., the pointed-to values don't change).

I'm making a semantic point: these values are special because they are 
at the other end of a certain set of "constant references". Not because 
they have any other property themselves, like being immutable.

> However, whether the
> references themselves are constant is independent of the issue at hand. The
> issue wouldn't change, for example, if Emacs relocated objects so that
> references were updated regardless of whether the objects' values were constant.

Object relocation is immaterial for the semantics of Elisp. Even if the 
objects were relocated from time to time, the references would be 
updated, and would point to the same objects again, and thus be constant.

>>> Whether an object is constant is distinct from whether it's derived from a
>>> self-evaluating form, because one can have constants that were never derived
>>> from any self-evaluating form.
>>
>> Examples?
> 
> One example is (aset (symbol-name 'car) 0 ?d), which I mentioned a while ago.
> Here's a trickier one:
> 
> (let ((constant-string (aref (symbol-function 'error) 1)))
>    (aset constant-string 0 183)
>    (number-sequence 0 1 0))
> 
> This also provokes undefined behavior at the C level while number-sequence is
> doing its thing; my Emacs dumps core, yours may do something different. I'm sure
> there are other examples. The point is that programs should not modify constants.

These two are pretty obviously "undefined behavior", and anybody who 
does that have only themselves to blame. So of course it's good to 
document this, but since apparently you're not going to fix the semantic 
problem currently under discussion yourself, I'm not sure I can keep 
this info. You're welcome to re-add it, of course.

> It would be nice if Emacs reliably signaled these errors and we should be able
> to do a better job of that than we're doing now. However, doing a better job
> would require interpreter surgery that would be too much for emacs-27.

Of course.

>>    A mutable object can become constant if it is part of an expression
>>    that is evaluated
>>
>> does add some cases not covered by self-evaluating forms, but those are more
>> complex cases (e.g. creating forms programmatically and then passing them to
>> 'eval'), and then the programmer might justifiably be expected to use their
>> head. The self-evaluating forms case is arguably less obvious.
> 
> The documentation should not limit itself to self-evaluating forms when
> discussing this problem area. Although it's OK for the doc to emphasize
> self-evaluating forms, they are not the whole story here.

The "whole story" can be enumerated in some place, sure. Self-evaluating 
forms seem to be the most important area to cover, though.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.