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 08:18:08 +0000 Message-ID: <87img4zjy7.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="39224"; 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 10:19:09 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 1jhU2n-000A5y-Dr for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 10:19:09 +0200 Original-Received: from localhost ([::1]:40216 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhU2m-00048D-D0 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 04:19:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhU1z-0002yR-FX for emacs-devel@gnu.org; Sat, 06 Jun 2020 04:18:19 -0400 Original-Received: from mail-qk1-x733.google.com ([2607:f8b0:4864:20::733]:44655) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhU1x-0000YZ-Gb for emacs-devel@gnu.org; Sat, 06 Jun 2020 04:18:19 -0400 Original-Received: by mail-qk1-x733.google.com with SMTP id c14so12242486qka.11 for ; Sat, 06 Jun 2020 01:18:17 -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=P1pbtFmX8YeGmwvQ2eF+zSqS9N95x56HgqtchQpWZlY=; b=Ylwc5GIy2vPwpwcOvrS8TmH4uudspnlv/yorXAhV5AYjBs7v8eb/wFwu3NkuQOOTXZ 3ihsXEv8cNMvvxWo95mHr1jrd3AE96bWSyTuOAqeVOz0ziTLPogIum5e/OHDMOJOcIr1 61l3sGl6133kSMB+5gDXgeRfxuFbPe02UHdPdLiUwQxfXJAsfz/edDB6yBlTIQ0USjoQ OcJHT3p3v/JSWtxineztPlw2H66AhH7W64PrgsJiTFD88cao5gzoKcsRWeK+WLutaUKw 1LjOKFkn4sxVhSWsMUZq27tGA9XmEY2Bj0IGFS37SYZy+g+FNALnIdHlrAkDxfGYU/uV xYgA== 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=P1pbtFmX8YeGmwvQ2eF+zSqS9N95x56HgqtchQpWZlY=; b=KmMUvNAeBCDsiXwaR469cBiij4DZ+NEGXnbp9JLVASU5FrPcoMHLf6UuVJ/EDlBCc2 d97wtYbFcAUPopuoop3bDbpSKBtELoVwBNZHJpCGvK6pPU+B4Zub5RbvWb25MXEpIqwM eCHarg+qkkzDcA26p+9S4Ek4vinRItO9nqETZyeRzM8GpOwH8znQ+1YHBz9TUzjjFZ3H Ek4Ybv2hR4Lbv9ueEzFD9MJ9IlVidf5U0mrbdtns4blcA4KlMUVc/Wg0nIMnEREpOtfc IoezCyIRPs2AduOwdd/KgpsKIskqelxM5nbOrCQH2SWeXEOKCFBEb3LSklhOoFL9aJ1i ppeg== X-Gm-Message-State: AOAM532W8g9YY2DWZOlHINsDUMi2C92CQq3/3GQ/12EZBQ6krwjcLWqu H3D2SJYLXzav7lGAg4VR6zXkUVFaWiA= X-Google-Smtp-Source: ABdhPJw4KCTHYL1WMyibDGGBN7fRR+ffA3yz1KYuhfj4fR3+okDqxi2VtZnVnfKmhzv/KdlaJdM7MA== X-Received: by 2002:a37:c20c:: with SMTP id i12mr14242259qkm.167.1591431496266; Sat, 06 Jun 2020 01:18:16 -0700 (PDT) Original-Received: from chametz (ns552097.ip-142-44-139.net. [142.44.139.12]) by smtp.gmail.com with ESMTPSA id s15sm2203599qtc.95.2020.06.06.01.18.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2020 01:18:15 -0700 (PDT) In-Reply-To: <5c66eeb5-a513-0443-4316-e41aae118677@cs.ucla.edu> (Paul Eggert's message of "Fri, 5 Jun 2020 11:17:47 -0700") Received-SPF: pass client-ip=2607:f8b0:4864:20::733; envelope-from=pipcet@gmail.com; helo=mail-qk1-x733.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:251937 Archived-At: Paul Eggert writes: > On 6/5/20 5:46 AM, Pip Cet wrote: >> I get the impression we >> shouldn't discount the possibility that the current way of doing things >> (after pure space) isn't so bad at all: all strings, vectors, and cons >> cells are mutable to the same extent. > > That's not the current way of doing things, and although the area is > murky there > have always been Emacs Lisp objects that are not mutable. Lately, only pure ones, as far as I can tell? > For example: > (aset (symbol-name 'cons) 0 ?d) > > This signals "Attempt to modify read-only object" error in Emacs 25, and makes > Emacs dump core in Emacs 27. And there are other cases like that. Well, dumping core is bad. The problem here is how pdumper "changed" pure space (actually, we're putting several megabytes of zeroes into every Emacs binary as a result) and how make_pure_c_string tries so very hard to save a few kilobytes of memory. Both problems, as I said, that wouldn't exist if we simply removed pure space. > Obviously we need to do better in the dumping-core area. When we do that, we > have an opportunity to simplify and/or document behavior in this area. Indeed. Simplify: remove pure space. Document: all strings, vectors, and cons cells are mutable to the same extent. > 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 doesn't violate the simple rule that as far as the Emacs core is concerned, all strings are equal. > This will > hurt performance a bit since it will disable some optimizations. Which ones? > If we decide to simplify/document by saying "an error is thrown if you try to > modify a string literal" then we'll need to add some code to do that. I have a 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". > draft of something along those lines. It doesn't hurt performance > significantly > in my standard benchmark of 'make compile-always'. (In general, I think that's probably not a good benchmark to optimize Emacs for). > Although it > invalidates some > existing code, such code is quite rare and is already relying on > undefined behavior. 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. > If we decide to leave things alone, they will remain complicated and murky. But I'd call the behavior you suggest even more complicated. I still think there's a significant risk that there will be ad-hoc changes that essentially commit us to a simplistic model of mutability. I don't think they're necessary or urgent, except for the make_pure_c_string bug you describe. For example, I think it might be very useful to have an immutable "view" of a mutable object (as in C, where I can pass a char * to a function expecting a const char *); that would mean storing the mutability flag in the Lisp_Object, not in the struct Lisp_String.