Subject: Re: bug#40671: [DOC] modify literal objects

From: Kevin Vigouroux <[email-masked]>
Date: Tue, 05 May 2020 22:48:44 +0200

Paul Eggert <[email-masked]> writes:

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

Would the expression "constant form" be appropriate? Here is the
definition given in the CLHS (in the glossary).

Constant form: Any form for which evaluation always yields the same
value, that neither affects nor is affected by the environment in which
it is evaluated (except that is permitted to refer to the names of
constant variables defined in the environment), and that neither affects
nor is affected by the state of any object except those objects that are
otherwise inaccessible parts of objects created by the form
itself. For instance, a car form in which the argument is a quote form is a
constant form.

If I understand correctly, the problem is partially related to self-modifying code.