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 18:40:17 -0700 Organization: UCLA Computer Science Department Message-ID: <205da0f6-2d15-249f-d1e2-ad1ae31002e6@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> <170bedfa-7119-4d6a-9d4f-e94ba0f7cc2b@default> <87pnacxbnk.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="67453"; 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" , Drew Adams , Pip Cet , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 07 03:41:14 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 1jhkJG-000HTQ-7I for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jun 2020 03:41:14 +0200 Original-Received: from localhost ([::1]:40232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhkJF-0006tc-9K for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 21:41:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47552) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhkIR-0006OW-Rt for emacs-devel@gnu.org; Sat, 06 Jun 2020 21:40:23 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhkIQ-0002sE-8M for emacs-devel@gnu.org; Sat, 06 Jun 2020 21:40:23 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C6AB71600E1; Sat, 6 Jun 2020 18:40:18 -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 N23VevFyamox; Sat, 6 Jun 2020 18:40:17 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C993A1600B5; Sat, 6 Jun 2020 18:40:17 -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 DQPDOgGJ7-8b; Sat, 6 Jun 2020 18:40:17 -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 7927B1600E1; Sat, 6 Jun 2020 18:40:17 -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: 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 21:40:19 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:251984 Archived-At: On 6/6/20 3:14 PM, Stefan Monnier wrote: > That makes me think there's been a fairly concrete proposal that has > been made and which I missed (since otherwise, it seems unclear how > you'd get to these conclusions). Can someone point me to it? There's no concrete proposal yet, in terms of published code. That being said, my idea is to change the Elisp interpreter to distinguish constant from mutable strings, and to have a runtime check in the few primitives (notably aset) that modify strings. String literals yield constant strings when evaluated. I wrote draft code to do this (this was after the long kerfuffle about mutability in the emacs-27 documentation), and the draft code has worked well so far. 'make check' passes, it can compile all the .el files and interactive use works fine for me. There is no runtime storage overhead. The CPU-time overhead is insignificant (i.e., so close to 0 that I can't measure it) in my usual benchmark of 'make compile-always' and from what I know about how Emacs and CPUs work I would expect similar results in other benchmarks (except for programs that mutate strings that they shouldn't :-). In the draft code there are no new primitives to create constant strings, test for mutability, or freeze strings. The only change in behavior visible to Lisp is that some currently undefined behavior becomes defined behavior. That is, when a program attempts to change a constant string an error is signaled, as opposed to the current undefined behavior when sometimes an error is signaled, sometimes Emacs dumps core, and sometimes Emacs behaves erratically afterwards. I am still testing the draft code, and am gradually shaking out its changes into master (you may have noticed some recent changes to alloc.c) that can be installed independently of the main change. There's no rush and I have other, more-urgent duties anyway. I am planning to publish the main change for discussion before installing it.