Re: master f51f963: Fix some side-effecting uses of make-text-button

[Pip Cet]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 6/5/20 5:46 AM, Pip Cet wrote:
>> I get the impression we
>> shouldn't discount the possibility that the current way of doing things
>> (after pure space) isn't so bad at all: all strings, vectors, and cons
>> cells are mutable to the same extent.
>
> That's not the current way of doing things, and although the area is
> murky there
> have always been Emacs Lisp objects that are not mutable.

Lately, only pure ones, as far as I can tell?

> For example:

> (aset (symbol-name 'cons) 0 ?d)
>
> This signals "Attempt to modify read-only object" error in Emacs 25, and makes
> Emacs dump core in Emacs 27. And there are other cases like that.

Well, dumping core is bad. The problem here is how pdumper "changed"
pure space (actually, we're putting several megabytes of zeroes into
every Emacs binary as a result) and how make_pure_c_string tries so very
hard to save a few kilobytes of memory. Both problems, as I said, that
wouldn't exist if we simply removed pure space.

> Obviously we need to do better in the dumping-core area. When we do that, we
> have an opportunity to simplify and/or document behavior in this area.

Indeed. Simplify: remove pure space. Document: all strings, vectors, and
cons cells are mutable to the same extent.

> If we decide to simplify/document by saying "all strings are modifiable" then
> we'll need significant work at both the C and Lisp level to do that.

I don't see why. All strings are modifiable, but the byte compiler will
identify strings under certain circumstances. That doesn't violate the
simple rule that as far as the Emacs core is concerned, all strings are
equal.

> This will
> hurt performance a bit since it will disable some optimizations.

Which ones?

> If we decide to simplify/document by saying "an error is thrown if you try to
> modify a string literal" then we'll need to add some code to do that. I have a

So far, what you have proposed is "an error is thrown if you try to
modify the characters of a string literal, or if you add text
properties unless it already has some, or if you remove the last text
property".

> draft of something along those lines. It doesn't hurt performance
> significantly
> in my standard benchmark of 'make compile-always'.

(In general, I think that's probably not a good benchmark to optimize
Emacs for).

> Although it
> invalidates some
> existing code, such code is quite rare and is already relying on
> undefined behavior.

I'm not sure "undefined behavior" is a useful term when speaking about
Emacs Lisp, except for behavior which is explicitly documented to be
unreliable. There's a single implementation, and a lot of code is
written to conform not to what's documented but to what happens to
work.

> If we decide to leave things alone, they will remain complicated and murky.

But I'd call the behavior you suggest even more complicated.

I still think there's a significant risk that there will be ad-hoc
changes that essentially commit us to a simplistic model of
mutability. I don't think they're necessary or urgent, except for the
make_pure_c_string bug you describe.

For example, I think it might be very useful to have an immutable "view"
of a mutable object (as in C, where I can pass a char * to a function
expecting a const char *); that would mean storing the mutability flag
in the Lisp_Object, not in the struct Lisp_String.