bug#40671: [DOC] modify literal objects

[Dmitry Gutov]

On 29.04.2020 03:04, Paul Eggert wrote:
> It's reasonable to have compile-time checking in a statically-typed language,
> though (as the above quote notes) the checking isn't adequate for C++ and one
> can get undefined behavior anyway in that language.

All the undefined-behavior stuff in the language is part of backward 
compatibility with C. Like I said, the same argument that says "you can 
change a const in C++" also says "string and int and void are basically 
the same type".

> And we could add some
> similar compile-time checking for the Elisp byte-compiler: it could warn about
> misuses like (aset "abc" 0 ?d), for example.

Not the worst idea. Won't work: it's a dynamic language. Hence the 
example of how a similar problem was dealt with in a fellow dynamic 
language that I wrote about a couple of messages ago.

> However, any such compile-time checking would be either too restrictive (with
> false positives)

The "too restrictive" end of the spectrum will result in prohibiting the 
user from modifying any and all conses.

> or only partial (with false negatives) or both (as in C++). So
> it wouldn't be an adequate substitute for documenting that some objects should
> not be changed.

With runtime checks, it could. But that might be too costly.

> I recall your using "literal object" but that's not a good choice of wording
> because the problem can occur with objects that are not literally present in any
> source code.

"Any object that is part of a literal value". You can probably extend 
that sentence to be exhaustive.

> By "elsewhere" I meant in other language documentation (C/C++/etc.), not
> elsewhere in the emacs-27 manual.

In "etc", you mentioned Common Lisp previously. Any idea how it deals 
with that problem?