emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pip Cet
Subject: Re: master f51f963: Fix some side-effecting uses of make-text-button
Date: Sun, 07 Jun 2020 09:31:58 +0000
User-agent: Gnus/5.13 (Gnus v5.13)

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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.

And, just once in a while, so very useful :-)

You're right, though, mutability of literals is a more serious concern
than mutability in general.

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

Mostly: don't make it harder to experiment with mutability by pretending
we already have anything like it.

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

Not at this point, no. I can describe the code I'm playing with, but
it's quite different and I'm not sure it's worth the considerable
performance cost...

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

I think the issue has been resolved: if I understand correctly, Paul is
probably going to propose an actual patch which makes strings immutable,
and we can discuss it then.

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

You're right, we should wait for such a proposal.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]