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

[Paul Eggert]

On 6/6/20 1:18 AM, Pip Cet wrote:

>> there have always been Emacs Lisp objects that are not mutable.
> 
> Lately, only pure ones, as far as I can tell?

There are others. I haven't cataloged them but they include builtin symbol
names, empty strings, and constant variables (no, I didn't come up with that
last term :-). Also numbers of course. Constants have always been ubiquitous in
Emacs.

>> 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's not how Emacs works now, and it's not how Common Lisp or Scheme works. If
we insisted on making the change you're proposing, it would throw yet another
obstacle into the path of porting Emacs to other platforms such as Guile. That
would not be a good road to take.

It might be worth making such a significant change if modifiable string literals
were an important feature that Elisp programmers urgently needed. But they're
not: they're rarely used, partly because when they have been used their use
often caused subtle bugs (as we've seen with make-text-button). They're not a
feature worth fighting for, any more than mutable numbers would be.

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

The ones Emacs is currently using, such as some strings are in read-only shared
memory, and some are coalesced. It would be unreasonable to coalesce strings if
they were mutable, since that would mean changing one would change the other.

> 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".

There must be some confusion here, as I haven't proposed that. What I'm thinking
of proposing (though I haven't written it up yet, and this is just an
off-the-cuff first cut) is that Emacs signal an error if a program attempts to
change a string constant's characters or text properties. That's a simple
notion, and it's something that Emacs long did for preloaded strings so it's not
like this would be a giant revolution. To my mind it's a considerably
more-conservative change than the one you're suggesting.

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

Admittedly it's crude but it is better than nothing and it is what we have
readily available. If you have another easy-to-use benchmark that would be
better, I'm all ears.

> 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.

Of course, and there's a natural tension between trying to document every
unimportant implementation detail (which would be a mistake) and not documenting
useful behavior (which would also be a mistake). But that's not the issue here,
as the behavior in question is explicitly documented to be unreliable and we're
discussing what (if anything) to do about it.