From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,
Paul Eggert <eggert@cs.ucla.edu>, Pip Cet <pipcet@gmail.com>,
emacs-devel@gnu.org
Subject: RE: master f51f963: Fix some side-effecting uses of make-text-button
Date: Sat, 6 Jun 2020 16:27:08 -0700 (PDT) [thread overview]
Message-ID: <f66d4ad0-d49d-41d6-ba97-a220973b09eb@default> (raw)
In-Reply-To: <jwvk10jq1t0.fsf-monnier+emacs@gnu.org>
> >> It might be worth making such a significant change if
> >> modifiable string literals were an important feature
> > They are, IMHO. A wonderful feature.
>
> I find it very hard to believe.
Me too. But that's my current vision, and I'm
stickin to it, until I see some good arguments
to the contrary.
Show me why we need (ever) to treat Elisp strings
as immutable, at least wrt their text properties.
> Either you're misunderstanding what we're talking about, or you do have
> some really off programming habits.
>
> Could you show some examples of code that rely of that "wonderful
> feature"? Extra points if such code is available in an existing
> Elisp package.
I don't have an example. I don't have any such
habit. And we don't yet have consistently, clean
mutable literal strings. Show me that we couldn't.
Elisp strings can have properties. You don't see
the properties when looking at code. Neither does
the Lisp reader etc.
I don't see why we would think of strings appearing
in Elisp code, i.e., literals, the way we think of
them in C, as fixed things, constant. It's natural
that a programmer might think that way. But I don't
see why it's important to the Elisp language that we
treat them that way. Please explain why it is.
What's lost by treating them the same way we treat
a value returned by `make-string' or `copy-sequence'?
The `make-text-button' example is maybe a good example
of why we shouldn't need to bother to constantize them.
Dunno; I didn't really follow that discussion.
TBH, I haven't thought about this before this discussion.
But I'm wondering now why we ever try to treat Elisp
strings as constants - wrt their properties, at least -
rather than as mutable objects.
Sure, it's unusual to think this way. But it's pretty
unusual for a language to have propertized strings in
the first place.
The case of strings is different from both conses and
symbols (with their properties), admittedly. And?
next prev parent reply other threads:[~2020-06-06 23:27 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
2020-06-06 22:16 ` Stefan Monnier
2020-06-06 23:27 ` Drew Adams [this message]
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=f66d4ad0-d49d-41d6-ba97-a220973b09eb@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.