From: Drew Adams <drew.adams@oracle.com>
To: Paul Eggert <eggert@cs.ucla.edu>, Pip Cet <pipcet@gmail.com>
Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel@gnu.org
Subject: RE: master f51f963: Fix some side-effecting uses of make-text-button
Date: Sat, 6 Jun 2020 13:11:01 -0700 (PDT) [thread overview]
Message-ID: <56bae185-9309-43f1-9727-11e89080cd12@default> (raw)
In-Reply-To: <1742051d-ff33-fe97-d0ee-83f55847d98a@cs.ucla.edu>
> It might be worth making such a significant change if
> modifiable string literals were an important feature
They are, IMHO. A wonderful feature. Other Lisps
should be so lucky.
> that Elisp programmers urgently needed.
Urgently? As in an emergency? No. That's a pretty
high bar. Do your proposed wholesale changes in the
other direction handle an emergency? Urgent?
> But they're not: they're rarely used,
Evidence? But let's assume your guess is right.
Is frequency of use really an important criterion
here?
List modification in Lisp is infrequent, but it's
very important to Lisp - always has been, outside
the use of "pure Lisp" for some research purposes.
> partly because when they have been used their use
> often caused subtle bugs (as we've seen with
> make-text-button).
That's because there are bugs in the implementation.
And because there's not corresponding doc everywhere.
The same thing is true of list-structure modification.
(I hope your next crusade won't be to prevent that!)
> They're not a feature worth fighting for,
Your opposite "feature" isn't, IMO.
> any more than mutable numbers would be.
Wrong. An Elisp string is an object, with properties.
When Elisp numbers get text properties your comparison
might make some sense.
> >> 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.
What's the cost in lost optimization? Any plan to
fiddle with optimization should weigh the gain and
loss.
To you, there's apparently no loss, because you see
no value in modifying string properties (or at least
that's not important enough to keep - to "fight for").
> What I'm thinking of proposing ... is that Emacs signal
> an error if a program attempts to change a string constant's
> characters or text properties.
Very not-good. What's next, impossibility to
modify list structure?
> That's a simple notion,
It sure is. Too simple. And unlispy.
> and it's something that Emacs long did for preloaded
> strings so it's not like this would be a giant revolution.
That some instances of a class of objects can be
immutable is very different from denying all such
objects the ability to change. Yes, that's a
giant, and ill-conceived, revolution.
> To my mind it's a considerably more-conservative
> change than the one you're suggesting.
"Conservative" or ultraconservative? It goes
backward IMO, tossing out an important feature of
Emacs Lisp.
next prev parent reply other threads:[~2020-06-06 20:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200604223056.17078.81265@vcs0.savannah.gnu.org>
[not found] ` <20200604223058.1850020A26@vcs0.savannah.gnu.org>
2020-06-04 22:44 ` master f51f963: Fix some side-effecting uses of make-text-button Stefan Monnier
2020-06-05 0:58 ` Paul Eggert
2020-06-05 9:27 ` Pip Cet
2020-06-05 10:51 ` Basil L. Contovounesios
2020-06-05 12:46 ` Pip Cet
2020-06-05 13:51 ` Basil L. Contovounesios
2020-06-05 14:31 ` Pip Cet
2020-06-05 15:48 ` Basil L. Contovounesios
2020-06-05 18:17 ` Paul Eggert
2020-06-06 8:18 ` Pip Cet
2020-06-06 16:57 ` Drew Adams
2020-06-06 17:57 ` Stefan Monnier
2020-06-06 19:00 ` Pip Cet
2020-06-06 19:49 ` Paul Eggert
2020-06-06 20:23 ` Drew Adams
2020-06-07 9:14 ` Pip Cet
2020-06-06 22:14 ` Stefan Monnier
2020-06-07 1:40 ` Paul Eggert
2020-06-07 15:24 ` Stefan Monnier
2020-06-07 23:42 ` Paul Eggert
2020-06-07 9:31 ` Pip Cet
2020-06-06 20:19 ` Drew Adams
2020-06-06 17:54 ` Paul Eggert
2020-06-06 19:41 ` Pip Cet
2020-06-06 20:15 ` Paul Eggert
2020-06-07 9:21 ` Pip Cet
2020-06-07 23:37 ` Paul Eggert
2020-06-06 20:11 ` Drew Adams [this message]
2020-06-06 22:16 ` Stefan Monnier
2020-06-06 23:27 ` Drew Adams
2020-06-05 13:02 ` Stefan Monnier
2020-06-05 13:50 ` Basil L. Contovounesios
2020-06-06 19:09 ` Paul Eggert
2020-06-06 20:19 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56bae185-9309-43f1-9727-11e89080cd12@default \
--to=drew.adams@oracle.com \
--cc=contovob@tcd.ie \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=pipcet@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.