RE: 31395511: "Don’t attempt to modify constant strings"

[Drew Adams <drew.adams@oracle.com>]

> > I don't think this matters much, since string
> > literals shouldn't have text properties.
> 
> Really? I've used the reader syntax for propertized
> strings a few times — it's pretty convenient.

+1.

And not just using reader syntax, i.e., not just
#("whatever" ...).  

"String literals shouldn't have text properties"
is an unhelpful and unlispy mantra.  It, in
effect, marginalizes the use of propertized
strings. And to what end - what's the gain that
offsets the loss?

"String literals appearing in code shouldn't be
implemented as constants" is a better mantra,
if we need a blanket point of view - hopefully
we don't.

Privileging byte-compiler optimizations such as
treating literal strings in code as constants,
over Lisp flexibility, is counter-productive
and not worth it.  What's lost is greater than
what's gained (presumably some space or speed).

Just as a (global) symbol is an _object_, with
properties, so can an Elisp string be.  That's
a powerful construct (missing in other Lisps).

Expecting users to use `make-string' or some
such, to avoid constant-string modification -
a la using `cons' or `list' to avoid modifying
constant list structure (e.g. quoted lists),
isn't very lispy, helpful, or reasonable.

This is true whether or not this has long been
problematic (accidentally or intentionally).

Users should be able to propertize a string
written literally in code, and change the
properties dynamically, over and over, without
inviting trouble.  They already know to use
`copy-sequence' when they need to ensure a new
string and not bother an existing one.  That
should be about all they ever need to do.

We should favor use of Elisp by Emacs users.
In general, we  shouldn't toss out flexibility
and convenience in an attempt to achieve
general-programming language features such as
high  performance.

It's OK to offer high performance if there's
no cost in convenience or flexibility, or if
that cost is really worth it.  And it's OK to
offer it optionally, where the sacrifice is an
intentional trade-off (by a user).

If you go the other way on this, then we at
least need to provide a simple way to
manipulate strings with properties - something
simpler than fiddling with `make-string' and
`copy-sequence' as often as we need to use
`cons', `list', and their backquote-comma
equivalents to avoid the gotcha of modifying
a quoted list.

If I use `copy-sequence' once, to ensure that
I don't bother an existing string, I should
be able to modify my new string over and over,
especially its text properties.

A quoted list that gets modified is bad enough
as a gotcha.  Many users never modify list
structure, and the doc makes clear when some
function does that.  And we try to document
that modify-quoted-list gotcha explicitly.
Not perfect, but we do try to help users with
that gotcha.

Modifying _symbol_ properties isn't a problem
because there is only ever one symbol with a
given name interned in a given obarray, and
the properties are separate from the obarray.
The obarray just holds the symbol identifier.

Modification of string properties needs to be
dealt with and documented reasonably, somehow.
Currently we can't rely on something like an
obarray, as we do with symbols.  And probably
more users will modify string properties than
list structure, so we need a solution that is
at least as good as the way we handle the list
gotcha.

Modifying the _chars_ in a string might be a
different story.  It's string properties I'm
mostly concerned about here.

We should look for a reasonable solution that
helps Emacs users, and not just favor compiled
code performance.

I know that more than the compiler is involved.
There's also the reader.  I'm asking for a
solution that makes modifying string properties
less, not more, problematic.

And barring any advance in the direction I'm
suggesting, let's at least try to give users
good, clear doc about whatever gotchas do exist
for modifying string text properties.  That's
not the best solution, but it's a necessary
fallback if nothing is improved in this regard
in the code.

Just one opinion.  +1 for propertized strings,
a wonderful Emacs-Lisp feature.