bug#40693: 28.0.50; json-encode-alist changes alist

[Paul Eggert <eggert@cs.ucla.edu>]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On 4/19/20 2:01 PM, Drew Adams wrote:

> 'foo returns the symbol foo.  Depending on the
> context, you can certainly modify the properties of
> that symbol - its `symbol-value', `symbol-function',
> and `symbol-plist'.

Thanks for catching that. I installed the attached further patch to fix that.

> The message should be about not _depending_ on a
> quoted value returning a new object (e.g. new list
> structure).  The message should not be that `quote'
> never returns a new object.

The message is already in the new "Constants and Mutability" section in the 
emacs-27 branch. No doubt the wording could be improved....

> A constant is not something that _should not_ be
> modified.  It's something that _cannot_ be modified.

This is merely a terminology issue; feel free to come up with better terminology.

[-- Attachment #2: 0001-Fix-mutability-glitches-reported-by-Drew-Adams.patch --]
[-- Type: text/x-patch, Size: 3444 bytes --]

From e1d42da0d686e93534ee2abebe79bff95f18cb4d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 19 Apr 2020 15:09:02 -0700
Subject: [PATCH] Fix mutability glitches reported by Drew Adams

See Bug#40693#32.
* doc/lispref/eval.texi (Self-Evaluating Forms, Backquote):
Say that these yield constant conses, vectors and strings,
not constant symbols.
* doc/lispref/objects.texi (Constants and Mutability): Say that an
attempt to modify a constant variable signals an error, instead of
saying that it has undefined behavior.
---
 doc/lispref/eval.texi    |  8 ++++----
 doc/lispref/objects.texi | 10 ++++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi
index deb288943a..f33c2faac1 100644
--- a/doc/lispref/eval.texi
+++ b/doc/lispref/eval.texi
@@ -158,8 +158,8 @@ contents unchanged.
 @end group
 @end example
 
-  A self-evaluating form yields a constant, and you should not attempt
-to modify the constant's contents via @code{setcar}, @code{aset} or
+  A self-evaluating form yields constant conses, vectors and strings, and you
+should not attempt to modify their contents via @code{setcar}, @code{aset} or
 similar primitives.  The Lisp interpreter might unify the constants
 yielded by your program's self-evaluating forms, so that these
 constants might share structure.  @xref{Constants and Mutability}.
@@ -704,8 +704,8 @@ Here are some examples:
 @end example
 
 If a subexpression of a backquote construct has no substitutions or
-splices, it acts like @code{quote} in that it yields a constant that
-should not be modified.
+splices, it acts like @code{quote} in that it yields constant conses,
+vectors and strings that should not be modified.
 
 @node Eval
 @section Eval
diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi
index 98b001afd2..b45eb7ad8a 100644
--- a/doc/lispref/objects.texi
+++ b/doc/lispref/objects.texi
@@ -2395,17 +2395,19 @@ somewhere else.
 
   Although numbers are always constants and markers are always
 mutable, some types contain both constant and mutable members.  These
-types include conses, vectors, and strings.  For example, the string
+types include conses, vectors, strings, and symbols.  For example, the string
 literal @code{"aaa"} yields a constant string, whereas the function
 call @code{(make-string 3 ?a)} yields a mutable string that can be
 changed via later calls to @code{aset}.
 
-  A program should not attempt to modify a constant because the
+  Modifying a constant symbol signals an error (@pxref{Constant Variables}).
+A program should not attempt to modify other types of constants because the
 resulting behavior is undefined: the Lisp interpreter might or might
 not detect the error, and if it does not detect the error the
 interpreter can behave unpredictably thereafter.  Another way to put
-this is that mutable objects are safe to change, whereas constants are
-not safely mutable: if you try to change a constant your program might
+this is that although mutable objects are safe to change and constant
+symbols reliably reject attempts to change them, other constants are
+not safely mutable: if you try to change one your program might
 behave as you expect but it might crash or worse.  This problem occurs
 with types that have both constant and mutable members, and that have
 mutators like @code{setcar} and @code{aset} that are valid on mutable
-- 
2.17.1