all messages for Emacs-related lists mirrored at yhetil.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 13:19:07 -0700 (PDT)	[thread overview]
Message-ID: <68198d80-34f2-4f06-b964-9157f4d43c9e@default> (raw)
In-Reply-To: <jwvd06cqdv7.fsf-monnier+emacs@gnu.org>

> > But going backwards, toward some perhaps unneeded
> > optimization, in the direction of systematically
> > raising an error when trying to modify text
> > properties of a string, is not a good idea, IMO.
> 
> I think there needs to be a clarification here: the issue is about
> modifying data (here specifically strings, but the issue applies to all
> other such data) that appears as literal in the code.

Yes, I know.

> This issue is not one of optimization (preventing those modifications
> would likely impose a slowdown, if anything) but one of detecting usage
> that is usually a bug (one that leads to people being utterly
> confused by the resulting behavior).

The resulting behavior now is undefined/unpredictable
in the problematic cases.  That's the problem.

List-structure modification too can result in
application bugs and confusion.  That's not a
reason, in Lisp, to prevent such modification.
Lisp, including Elisp, gives you lots of rope
to hang yourself with.

A "literal" string occurrence in code is what
the implementation of Emacs defines it to be.

Strings can have text properties.  Those are not
visible as program text (code, viewed lexically).
Maybe no strings in Elisp should really be
considered "literal" in the usual sense.

Unless some sophisticated analysis takes place,
to determine that no modification of a given
string's properties will/can/might take place,
there are two "extreme" positions possible:

1. Disallow modification of a string's text props.
2. Allow modification of a string's text props.

Something in between is also possible.  We have
something in between now, but it's unclear or
undefined or accidental.

As I understand it, Paul proposes extreme #1.
I'm closer to extreme #2.

But I say that any backtracking from #2, and
especially any backtracking from what Emacs has
had so far (ad hoc, accidental, partial, or what
have you) - any considering a string ("literal"
or not) as needing an error to be raised if an
attempt is made to change its text properties
(including adding some when there are none) is
a loss.

And any such loss needs to have a good supporting
argument - as strong an argument as for raising
an error for list-structure modification where
today there's no such error-raising.

Elisp programmers need to be able to do both:
(1) program without structure modification (list,
string, whatever), and (2) program using such
modification.

And the "literal" case really shouldn't, I think,
be a special one.  I think that now, even for a
quoted list, but I won't argue that case.  (A
quoted list is clear just from the program text.
A propertized string is not clear textually, in
the general case.)

I don't expect others to hold the same "extreme"
position.  But that's the direction I'm thinking
in now, FWIW.  And so far I haven't seen any good
arguments in the other direction.

We heard arguments about important "optimization".
You've tossed that aside now, at least for literal
strings, saying there's no such optimization and
in fact there may be a performance cost.

Your argument is instead the value in "detecting
usage that is usually a bug (one that leads to
people being utterly confused by the resulting
behavior)".

That needs to be shown.  And not just by pointing
to the current all-bets-are-off situation in terms
of understanding.  Please make the argument in terms
of a situation where every string is considered to
have modifiable text properties (extreme #2).

When I see a good argument against #2, maybe I'll
pull back from it a bit. ;-)

Certainly, the general argument against this kind
of thing _is_ in terms of (1) simplicity of program
analysis and (2) performance.  It's the argument of
compilation vs interpretation, more or less.

I'd argue that Emacs Lisp is, among all the Lisps,
the one where use by end users of the result is the
most important, and interpretation (vs compilation)
is relatively more important than for other Lisps,
and performance and static (lexical) analysis is
relatively less important.

(And that's from someone who wishes that Elisp would
take more from Common Lisp, which is far from #2.)




  parent reply	other threads:[~2020-06-06 20:19 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 [this message]
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
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=68198d80-34f2-4f06-b964-9157f4d43c9e@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.