all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "João Távora" <joaotavora@gmail.com>, "Dmitry Gutov" <dgutov@yandex.ru>
Cc: Paul Eggert <eggert@cs.ucla.edu>, Pip Cet <pipcet@gmail.com>,
	emacs-devel <emacs-devel@gnu.org>
Subject: RE: 31395511: "Don’t attempt to modify constant strings"
Date: Fri, 5 Jun 2020 17:23:31 -0700 (PDT)	[thread overview]
Message-ID: <adde6434-ee32-4832-9017-ada32def296f@default> (raw)
In-Reply-To: <87d06dje3d.fsf@gmail.com>

> > But you can give bug#40671 a read, so see some context you might be
> missing.
> 
> Thanks, that's a pretty long read.  There is indeed a relation, but that
> bug (the first parts) is about modifying literal objects and this
> particular strangeness seems bigger than that.
>
> I totally agree it is undefined behaviour to change structure
> of literals (quoted or self-evaluating objects), also in
> Common Lisp, because compilers are probably allowed to reuse
> parts of the internal structure of such objects.

Yes.  But Common Lisp is a general-programming
language.  Elisp is for use with Emacs.  And it
has strings that have properties, like symbols.

> But that's a far cry from having two different manifestations
> of `equal` such objects _be_ the same object, but only for compiled
> code.  Emacs doesn't behave that way for quoted lists (fortunately), so
> I don't think it should behave that way for strings either.

+1.

> An "easy" solution would be to say: in Elisp, there
> are no string literals, period, because properties.

+1.  Clean, flexible (dunno how "easy").

> But that's likely expensive...

Do we have an idea how expensive?  Lots of things
are expensive.  And some of them are worth it.

OK, some Elisp code might make heavy, repeated use
of long strings, and maybe some such uses would pay
a penalty.  Not sure though that the penalty would
be large, or "too large".

And most Elisp code won't be like that, I expect.

Maybe we could have a Boolean variable (which could
be made file-local or buffer-local on demand).

You could turn it on in some scope or for some
extent, to enable some string optimization at the
cost of either an occasional gotcha or systematic
error-raising when you try to modify etc.

Maybe that decision would need to be made at
byte-compile time, or maybe the compiled code could
(at the cost of being larger) respect it.

> unless some clever copy-on-write semantics operate
> under the hood.  But I'm talking out of my elbow,
> I don't really know what's under the hood here.

Nor do I, obviously.  I just have a hunch that,
in general, string optimization isn't worth it for
most Lisp code used in Emacs - not worth the loss
of being able to comfortably and generally modify
string properties.



  parent reply	other threads:[~2020-06-06  0:23 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03 21:52 31395511: "Don’t attempt to modify constant strings" João Távora
2020-06-03 22:41 ` Paul Eggert
2020-06-03 22:52   ` Pip Cet
2020-06-03 23:20     ` Paul Eggert
2020-06-03 23:20     ` Basil L. Contovounesios
2020-06-03 22:41 ` Pip Cet
2020-06-03 23:08   ` Basil L. Contovounesios
2020-06-03 23:31     ` Basil L. Contovounesios
2020-06-03 23:48   ` João Távora
2020-06-04  0:43     ` Paul Eggert
2020-06-04  1:19       ` Paul Eggert
2020-06-04  7:26         ` Pip Cet
2020-06-04 11:11           ` Basil L. Contovounesios
2020-06-04 19:46             ` Paul Eggert
2020-06-04 20:25               ` João Távora
2020-06-04 20:29                 ` Paul Eggert
2020-06-04 21:21                   ` Drew Adams
2020-06-04 20:43               ` Pip Cet
2020-06-04 21:27                 ` Stefan Monnier
2020-06-04 21:42                   ` Pip Cet
2020-06-04 23:10                 ` Paul Eggert
2020-06-05  2:09                   ` Clément Pit-Claudel
2020-06-05  6:44                     ` Paul Eggert
2020-06-05 12:44                       ` Stefan Monnier
2020-06-05 17:01                     ` Drew Adams
2020-06-05  9:48                   ` Pip Cet
2020-06-05 18:37                     ` Paul Eggert
2020-06-04 22:33               ` Basil L. Contovounesios
2020-06-05 15:25       ` João Távora
2020-06-05 17:14         ` Dmitry Gutov
2020-06-05 23:19           ` João Távora
2020-06-05 23:32             ` Dmitry Gutov
2020-06-06  1:34               ` FW: " Drew Adams
2020-06-06  0:23             ` Drew Adams [this message]
2020-06-06  1:43             ` Paul Eggert
2020-06-06  4:06               ` Richard Stallman
2020-06-06 11:41               ` João Távora
2020-06-06 11:47                 ` João Távora
2020-06-04  4:38     ` Pip Cet
2020-06-04  9:31       ` João Távora

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=adde6434-ee32-4832-9017-ada32def296f@default \
    --to=drew.adams@oracle.com \
    --cc=dgutov@yandex.ru \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    --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.