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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I don't see how literal data is special that way.

In code

    (let ((x "foo"))
      (cl-assert (eq (aref x 0) ?f))
      ...)

every programmer I know expects the assertion to be true, always, no
matter what.  Yet the assertion will fail if `...` does something like
(aset x 0 ?o).

That's what makes literals special.

This is not unique to Lisp [ tho Lisp experiences this much more because
of the presence of `quote` which makes it possible and common to have arbitrary
literals embedded in the code.  ]

IIRC, in C the standard says that modifying a string literal has
undefined behavior.

> If I expect a function to look at a string argument, but it actually
> modifies its argument, that's equally confusing.

I hate mutability, yes.  But mutability of literals amounts to
self-modifying code, which is yet a bit more evil.

> If I modify data that's been used in a hash key, that's even more
> confusing. If I modify data in an image spec in a Lisp callback from
> the image backend, Emacs will crash.  These cases deserve being
> thought about, too.

We agree, but I'm not sure what it is you're suggesting we should do.
We obviously can't make existing data types unilaterally immutable since
it would break way too much code.  Are you suggesting we add new
constructors for "immutable cons", "immutable string", ...?
Or a `set-immutable` function?

> The cost of this isn't negligible; the single bit which I expect will be
> kept for every string, cons cell, or vector isn't that significant, but
> so far what's been proposed would be complicated to implement, explain,
> and use.

I'm not exactly sure what has been suggested, to be honest.
Are you referring to the idea of making literal strings immutable?
I'm not sure what is the implementation plan for such a thing.
It seems at least not completely straightforward.

> It would lead to some people developing a false sense of security and
> others becoming insecure and copying everything needlessly (and
> dangerously, for cyclic objects). And it would effectively prevent any
> competing system of mutability, I fear.

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?


        Stefan