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

Previous Next

Package: emacs;

Reported by: Kevin Vigouroux <ke.vigouroux <at> laposte.net>

Date: Thu, 16 Apr 2020 20:40:02 UTC

Severity: normal

Tags: patch

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: ke.vigouroux <at> laposte.net, Richard Stallman <rms <at> gnu.org>, Michael Heerdegen <michael_heerdegen <at> web.de>, Mattias Engdegård <mattiase <at> acm.org>, Drew Adams <drew.adams <at> oracle.com>, 40671 <at> debbugs.gnu.org
Subject: bug#40671: [DOC] modify literal objects
Date: Sun, 10 May 2020 18:57:00 -0700
On 5/10/20 5:44 PM, Dmitry Gutov wrote:

> "Indeed"?

Indeed yes. :-)

> The changing "mutability" status is imaginary, however.

It's part of a spec. Not every constraint in a spec needs to be enforced
directly by the implementation. That doesn't mean these constraints are "imaginary".
> This also requires the reader to read the manual without missing a reference. A
> regular person would not understand your meaning of "mutable" without following
> the reference to {Mutability}.

If a paragraph says "mutable" and has a cross-reference to the "Mutability"
section, that's good enough. This is a reference manual, not a tutorial, and we
can assume a reasonable level of competence on the part of the reader.
> Does is ignore the possibility of the example in the previous version, then?

I don't understand this remark.

> I'm trying to point out the incompatibility with the regular meanings of the
> words used.

>> Because it's not an accurate statement of the problem. The set of objects that
>> might be shared differs from the set of objects that should not change. The
>> Mutability node focuses on the latter set of objects, and gives the former as an
>> example but it is not the only sort of object that should not change.
> 
> But if we don't mention such cases in "Mutability", where do we cover them?

Fair enough. I added an example of such a case to "Mutability" in the proposal
in my most-recent email (Bug#40671#441).
> +(let* ((x (list 0.5))
> +       (y (eval (list 'quote x))))
> +  (setcar x 1.5) ;; The program should not do this.
> +  y)
> 
> Why is this a problem? Do we expect this it could lead to a segfault?

Probably not a segfault in the current implementation, but the behavior isn't
defined. And we don't want the behavior to be defined, as that would prohibit
some optimizations that may be coming down the road.




This bug report was last modified 5 years and 2 days ago.

Previous Next


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