unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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?



  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).