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

[Pip Cet]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> @@ -202,7 +202,7 @@ The format has been repaired and the variable modified 
>>> accordingly.
>>>  You can save the current value through the customize system by
>>>  either clicking or hitting return "
>>>            (make-text-button
>>> -           "here" nil
>>> +           (copy-sequence "here") nil
>>>             'face '(:weight bold :inherit button)
>>>             'mouse-face '(:weight normal :background "gray50" :inherit 
>>> button)
>>>             'follow-link t
>>
>> So, here why do we need to `copy-sequence`?
>
> To avoid destructively modifying a string literal by placing properties
> on it.

I think adding a concept of mutability/constness/finality/... could be a
great extension of the ELisp language.

It would also be a very significant change of that language, perhaps
comparable to "true" multi-threading.

It would not be a quick bug fix for code that uses (propertize "string"
'a 'b).

In particular, I'm not convinced code like that is buggy at all. It's
true that it will fail under certain conditions (the string constant is
used again in the same function, the function is byte compiled, that
sort of thing), and it's true there are better ways of doing that, but
is that reason enough to off-handedly ban all such code?

I probably don't even know half of it, but there are so many overlapping
concepts ("const" in C, "constexpr" in C++, "final" in Java, "const" in
JavaScript, "frozen" objects in Python...) that 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.

I think it's worth it to experiment with other concepts of mutability,
perhaps on a feature branch, but I don't think that's true for a concept
that, so far, appears to be "literal strings can't be given text
properties unless they already have at least one, in which case you can
alter their text properties but not remove them all".

I'll take all of that back if I actually see a bug that means Lisp code
can cause an Emacs crash (in the C sense of "crash") by mutating literal
strings, and that can't easily be fixed in C, and isn't actually a known
limitation of the byte compiler.

My guess is a concept of immutability won't be very useful if it's just
a single bit telling you "this object is immutable": we need to attach
more information to it, perhaps going as far as providing special ways
of mutating the object rather than simply signalling an information-free
error. (So, for example, a vector could be defined in Lisp to coerce all
of its entries to nil or t, so we wouldn't need bool vectors anymore).

Sorry this got long, but I don't understand the rush to actually commit
to what appears to me to be a simplistic model of mutability when we
haven't even removed the previous one, which I believe we've outgrown:
pure space.

(I think we should also get rid of the hash table mutability thing
again, but that's another discussion entirely).