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

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dmitry Gutov <dgutov <at> yandex.ru>, 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: bug#40671: [DOC] modify literal objects
Date: Mon, 4 May 2020 10:52:18 -0700

On 5/4/20 3:16 AM, Dmitry Gutov wrote:
> On 04.05.2020 02:10, Paul Eggert wrote:
>> The term you used was "Objects referenced from executable code". But that term
>> includes pretty much every object used in Elisp, at least until the object
>> becomes unreachable and is garbage-collected.
> 
> I see. Could you present a specific counter-example, however?
> 
> One where the phrasing "referenced from executable code" would apply, but "part
> of expressions that are evaluated" wouldn't.

Pretty much any ordinary cons will do.  In (let ((x (cons 0 0))) (setcar x 1)),
for example, the cons is referenced from executable code but it's OK to modify
the cons. The cons becomes unreachable when the 'let' finishes. The cons is not
part of any expression that is evaluated.

The problem here evidently is one of terminology, not of understanding the
underlying issues. When I read "Objects referenced from executable code" I
evidently got a different meaning than what you intended. These things happen
when introducing a new terminology.

Previous Next

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