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

[Paul Eggert]

On 6/6/20 3:14 PM, Stefan Monnier wrote:
> That makes me think there's been a fairly concrete proposal that has
> been made and which I missed (since otherwise, it seems unclear how
> you'd get to these conclusions).  Can someone point me to it?

There's no concrete proposal yet, in terms of published code. That being said,
my idea is to change the Elisp interpreter to distinguish constant from mutable
strings, and to have a runtime check in the few primitives (notably aset) that
modify strings. String literals yield constant strings when evaluated.

I wrote draft code to do this (this was after the long kerfuffle about
mutability in the emacs-27 documentation), and the draft code has worked well so
far. 'make check' passes, it can compile all the .el files and interactive use
works fine for me. There is no runtime storage overhead. The CPU-time overhead
is insignificant (i.e., so close to 0 that I can't measure it) in my usual
benchmark of 'make compile-always' and from what I know about how Emacs and CPUs
work I would expect similar results in other benchmarks (except for programs
that mutate strings that they shouldn't :-).

In the draft code there are no new primitives to create constant strings, test
for mutability, or freeze strings. The only change in behavior visible to Lisp
is that some currently undefined behavior becomes defined behavior. That is,
when a program attempts to change a constant string an error is signaled, as
opposed to the current undefined behavior when sometimes an error is signaled,
sometimes Emacs dumps core, and sometimes Emacs behaves erratically afterwards.

I am still testing the draft code, and am gradually shaking out its changes into
master (you may have noticed some recent changes to alloc.c) that can be
installed independently of the main change. There's no rush and I have other,
more-urgent duties anyway. I am planning to publish the main change for
discussion before installing it.