bug#40671: [DOC] modify literal objects

[Paul Eggert]

On 5/17/20 5:39 AM, Dmitry Gutov wrote:

> An existence of a technical term doesn't really cancel out the regular meaning
> of the word.

I continue to be skeptical that "constraints are always enforced" is the regular
meaning of the word "constraints" in computing. Lots of constraints are not
enforced in the computing world. Internet RFCs are a classic example: "Be
liberal in what you accept" means "Don't enforce constraints".

But again, we are straying from the point at hand, as the word "constraints"
isn't used in the documentation when talking about mutability.

> 1. You seem to be trying to redefine the term "motable" as a way to avoid
> enumerating all possible cases.

That is a normal practice for definitions, and this practice increases the
utility of the documentation. The Emacs manual defines "string" without
enumering all possible cases of strings (whether they come from the program
text, or from reading input, or from symbol-name, etc.) because enumerating all
cases would be bloat that would cause more harm than good. Similarly, the manual
defines "mutable" without defining all possible cases of mutable objects.
> 2. symbol-name seems like something we don't have to explain specially.

I don't understand this comment. symbol-name is just an example. It's helpful to
have an example or two, even if they're not absolutely required.

> There's an argument to be made that the name of the symbol 'cons is part of 
> any
> expression or program that uses `cons'.

Sure, and that argument is part of any bigger project to document more about
mutability ("covering all the cases" in some way). This would not be a trivial
project, and it's not something we have to do today.

> My intuition, though, that making cases like the one you just changed in 
> emacs-lisp-mode-tests.el blow up at runtime will create a massive backward 
> incompatibility. 

I'm sure there are compatibility issues. But we already have those issues: an
Elisp program that modifies a string constant is already "broken" in that it's
making assumptions that have never been documented and are sometimes not true
even now. Emacs used to have some runtime checking for this bug but it doesn't
now, and when we reinstitute checking we will undoubtedly shake out some latent
bugs in user code.