From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: master f51f963: Fix some side-effecting uses of make-text-button Date: Sat, 6 Jun 2020 10:54:46 -0700 Organization: UCLA Computer Science Department Message-ID: <1742051d-ff33-fe97-d0ee-83f55847d98a@cs.ucla.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="34571"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: "Basil L. Contovounesios" , Stefan Monnier , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 19:55:45 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 1jhd2m-0008sb-Ts for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 19:55:45 +0200 Original-Received: from localhost ([::1]:55652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhd2l-0004vk-UP for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 13:55:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhd23-0004PZ-1g for emacs-devel@gnu.org; Sat, 06 Jun 2020 13:54:59 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33860) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhd1z-0003YV-9T for emacs-devel@gnu.org; Sat, 06 Jun 2020 13:54:58 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A69771600E0; Sat, 6 Jun 2020 10:54:51 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1D2nuZ3pCSD0; Sat, 6 Jun 2020 10:54:50 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5CE361600E1; Sat, 6 Jun 2020 10:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aF5sVxif_4mB; Sat, 6 Jun 2020 10:54:50 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id F028E1600E0; Sat, 6 Jun 2020 10:54:49 -0700 (PDT) Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoU In-Reply-To: <87img4zjy7.fsf@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/06 13:54:51 X-ACL-Warn: Detected OS = Linux 3.1-3.10 X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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:251955 Archived-At: 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, empty strings, and constant variables (no, I didn't come up with that last term :-). Also numbers of course. Constants have always been ubiquitous in Emacs. >> 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, and it's not how Common Lisp or Scheme works. 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. 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. >> 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, and some are coalesced. It would be unreasonable to coalesce strings if they were mutable, since that would mean changing one would change the other. > 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. 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. That's a simple notion, and it's something that Emacs long did for preloaded strings so it's not like this would be a giant revolution. To my mind it's a considerably more-conservative change than the one you're suggesting. > (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. > 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.