From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: master f51f963: Fix some side-effecting uses of make-text-button Date: Sat, 06 Jun 2020 19:41:41 +0000 Message-ID: <87lfl0x9qi.fsf@gmail.com> References: <20200604223056.17078.81265@vcs0.savannah.gnu.org> <20200604223058.1850020A26@vcs0.savannah.gnu.org> <87eeqtiy4x.fsf@tcd.ie> <87img51y04.fsf@gmail.com> <5c66eeb5-a513-0443-4316-e41aae118677@cs.ucla.edu> <87img4zjy7.fsf@gmail.com> <1742051d-ff33-fe97-d0ee-83f55847d98a@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="121539"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: "Basil L. Contovounesios" , Stefan Monnier , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 21:52:26 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jheri-000VWk-5H for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 21:52:26 +0200 Original-Received: from localhost ([::1]:47376 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jherh-0007lx-5A for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 15:52:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43514) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhehW-0003S3-MI for emacs-devel@gnu.org; Sat, 06 Jun 2020 15:41:54 -0400 Original-Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]:36488) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhehU-0001Sx-PK for emacs-devel@gnu.org; Sat, 06 Jun 2020 15:41:54 -0400 Original-Received: by mail-ej1-x632.google.com with SMTP id z5so13888374ejb.3 for ; Sat, 06 Jun 2020 12:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=lE/9t5A730uLIJs66tg26TBEmBaEshWSHPvbsyqwPMw=; b=pLZqugockWp+j8+88DyBwUQIeRtfsy5pD6yaivs5bgNIEjTmzr3N8y+OBfhhzbaR0b MLEfmpZN8dMs2G6M8V9DhQ/kwmHGNWMgIkwVQQ3iy/DJYy7Y/iR5Uyx37DwFjsAme5Vg 81fU8JSczlpjjlza1ZTe7LmpctuSL6V9EnI3nMfPF14iUOmoZE/AX3pUXUC/FraatrIq 9voNm7D4NpwpNS3AFb2fa6K15AvK6xqfkkiFs8pDOgnMb6u4A99Dua6LrxYM/E8+yLZW zXQRkphlOPS1d+JMHVgg2Vcpl4lPPT6SocmANfGq58ZSUbgunC12MfcgRLlTirSFq8R7 SAKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=lE/9t5A730uLIJs66tg26TBEmBaEshWSHPvbsyqwPMw=; b=RByDPhhvmSSqdN/bnmptmcn/XK6hl09x7MjY+mXY2uJ2msVbV+3jkzfcTvqFzv4SvX iWH63f/eXunr5NUmU8JRu6HsAD2M1v1MnsN1nk9GjPeBarstpb1zkhhWLs9kOnGn2fII LcURHIqHCeY4aOSCqmEvpCakkInTB66ULjSqxMkVmtrFDSn+9vZecKwfnt46f0/UGs6C egUL1ZygVtPsmRaVN8DOWWJeJwbV5COlYKPyn8Q5BmVVrqFNurjl2eD8nmPI8PLaC1Ds R7iu/QHXckQ08obpQMbWL44A7XXuxmVBpkCHyY52CsBTmDwkVvBOEfzjfxpkD+EzYpiI CRHw== X-Gm-Message-State: AOAM531fnWcyAV48iPv3uUAkmhtl9xUWP37tq7qB26RK6V7g0sUX3l47 Pps8bZCiw/pvdHx/27wid5KD2Da0oLU= X-Google-Smtp-Source: ABdhPJxXndhEKlxy1b70plWo5TfB8Dbt42iOiMfa7c8b+SWHAt1T1/WJMKK/2P3zvwj1lLD0QIr7Lw== X-Received: by 2002:a17:907:1110:: with SMTP id qu16mr14861400ejb.539.1591472510894; Sat, 06 Jun 2020 12:41:50 -0700 (PDT) Original-Received: from chametz ([81.17.16.149]) by smtp.gmail.com with ESMTPSA id gt26sm6964562ejb.107.2020.06.06.12.41.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2020 12:41:50 -0700 (PDT) In-Reply-To: <1742051d-ff33-fe97-d0ee-83f55847d98a@cs.ucla.edu> (Paul Eggert's message of "Sat, 6 Jun 2020 10:54:46 -0700") Received-SPF: pass client-ip=2a00:1450:4864:20::632; envelope-from=pipcet@gmail.com; helo=mail-ej1-x632.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251963 Archived-At: Paul Eggert writes: > On 6/6/20 1:18 AM, Pip Cet wrote: > >>> there have always been Emacs Lisp objects that are not mutable. >> >> Lately, only pure ones, as far as I can tell? > > There are others. I haven't cataloged them but they include builtin symbol > names pure > empty strings, pure, and as modifiable as all other strings > and constant variables (no, I didn't come up with that > last term :-). Also numbers of course. I don't think setting a symbol's values is comparable to mutating a vector or string. Neither are numbers. > Constants have always been > ubiquitous in > Emacs. I disagree, to me immutable objects appear to be the strange exception. >>> If we decide to simplify/document by saying "all strings are >>> modifiable" then >>> we'll need significant work at both the C and Lisp level to do that. >> >> I don't see why. All strings are modifiable, but the byte compiler will >> identify strings under certain circumstances. > That's not how Emacs works now, Very close, though. > and it's not how Common Lisp or Scheme works. Neither is anything that has been proposed by you so far. > If > we insisted on making the change you're proposing, it would throw yet another > obstacle into the path of porting Emacs to other platforms such as Guile. That > would not be a good road to take. "Yet another" is the important term here, I think. There are more significant issues to sort out. > It might be worth making such a significant change if modifiable > string literals > were an important feature that Elisp programmers urgently needed. But they're > not: they're rarely used, partly because when they have been used their use > often caused subtle bugs (as we've seen with make-text-button). They're not a > feature worth fighting for, any more than mutable numbers would be. I agree, actually. What I'm fighting against is a certain model of immutability being installed into the Emacs source tree and effectively preventing better ones from ever having a chance, as well as turning out to be, as the vast majority of such models have, a problem rather than a useful feature. > >>> This will >>> hurt performance a bit since it will disable some optimizations. >> >> Which ones? > > The ones Emacs is currently using, such as some strings are in > read-only shared > memory, I don't think that's even an optimization. As I said, we're not aggressively reducing the size of the Emacs binary, quite the opposite, and read-only strings copied into pure space probably wouldn't be paged in. > and some are coalesced. Just to be clear: nothing in Emacs "coalesces" two strings by making them equal if they weren't before. The byte compiler generates new strings, and might generate fewer than were put in, but a string always has its own identity and keeps it. > It would be unreasonable to coalesce > strings if > they were mutable, since that would mean changing one would change the > other. Strings are mutable, and we are "coalescing" them, if only in the weak sense that the byte compiler does. > >> So far, what you have proposed is "an error is thrown if you try to >> modify the characters of a string literal, or if you add text >> properties unless it already has some, or if you remove the last text >> property". > > There must be some confusion here, as I haven't proposed that. I'm sorry for misunderstanding, then. > What > I'm thinking > of proposing (though I haven't written it up yet, and this is just an > off-the-cuff first cut) is that Emacs signal an error if a program attempts to > change a string constant's characters or text properties. Okay. I'm sorry I assumed you were just going to go ahead and commit something without any prior discussion, and it would be unfair not to wait for that proposal before criticizing it. >> (In general, I think that's probably not a good benchmark to optimize >> Emacs for). > > Admittedly it's crude but it is better than nothing and it is what we have > readily available. If you have another easy-to-use benchmark that would be > better, I'm all ears. Let me second that, I would love to have a better benchmark. >> I'm not sure "undefined behavior" is a useful term when speaking about >> Emacs Lisp, except for behavior which is explicitly documented to be >> unreliable. There's a single implementation, and a lot of code is >> written to conform not to what's documented but to what happens to >> work. > > Of course, and there's a natural tension between trying to document every > unimportant implementation detail (which would be a mistake) and not > documenting > useful behavior (which would also be a mistake). But that's not the > issue here, > as the behavior in question is explicitly documented to be unreliable > and we're > discussing what (if anything) to do about it. I'm not sure whether I've lost the right to comment on changes made all of six weeks ago, because I must admit I hadn't been aware of those documentation changes. I think you've essentially documented the changes you're considering to propose as though they had already happened. I think there are solutions here we'd both be happy with: we can easily use the C preprocessor to generate the amount of mutability checking we want, ignoring all or some of the information passed to the macros. But if we want that C API to be flexible enough to allow unusual applications (and isn't that what Emacs is all about?), it needs something more than just the obvious CHECK_MUTABLE (obj) macro.