On 4/20/20 3:05 AM, Štěpán Němec wrote:

> how about, rather than giving examples that you would
> never use in real code, we change the examples as follows:
> 
>            (assq "simple leaves" leaves)
>                 ⇒ unspecified ; might be nil or non-nil
>            (assoc "simple leaves" leaves)
>                 ⇒ ("simple leaves" . oak)

Yes, that's fine. I installed the attached patch, which attempts to address 
this, along with other comments by you and Drew.

> Similarly for the others.

What similar examples are there? As far as I can tell, the other 
newly-introduced uses of copy-sequence are needed for mutability not uniqueness, 
so they aren't similar.

> the examples you give IMO
> don't illustrate that some strings or lists are mutable and some are
> not; it illustrates that mutating some lists or strings has undefined
> consequences.

I have a different impression, I think the string that (symbol-name 'lambda) 
returns really is constant. Currently Emacs doesn't behave well if you try to 
change that string (and Emacs should behave better): but it's a feature not a 
bug that you can't mess up the Lisp interpreter in such a fundamental way, and 
if we make improvements in this area they should not change the fact that these 
string values should stay constant.

> The point I have been trying to make is that, especially now that
> immutable (/persistent/functional) data structures are quite widespread,
> using the mutable/immutable dichotomy in the way you do for Elisp is
> confusing

But the Elisp documentation doesn't contrast "mutable" with "immutable"; it 
contrasts "mutable" with "constant". The documentation avoids the word 
"immutable" partly to try to avoid the confusion that you mention.

There are other languages where "constant" or "const" means "behavior is 
undefined if you try to change it", not "an exception is thrown if you try to 
change it"; C and C++ are notable examples. So it's not like the documentation 
is inventing terminology out of whole cloth here.

If one's expectation is that Emacs will throw an exception if one tries to 
modify a constant then that's unfortunate, because Emacs doesn't do that for all 
constants. For now, the manual documents what you can do safely in a Elisp code; 
if we improve Emacs so that it reliably signals an error when you try to modify 
any constant then we can change the manual to say so.