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: Fri, 05 Jun 2020 12:46:19 +0000 Message-ID: <87img51y04.fsf@gmail.com> References: <20200604223056.17078.81265@vcs0.savannah.gnu.org> <20200604223058.1850020A26@vcs0.savannah.gnu.org> <87eeqtiy4x.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="1331"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stefan Monnier , emacs-devel@gnu.org To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 05 14:47: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 1jhBka-0000DY-9q for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 14:47:08 +0200 Original-Received: from localhost ([::1]:58248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhBkZ-0007LK-Bh for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 08:47:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35294) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhBjx-0006v6-2e for emacs-devel@gnu.org; Fri, 05 Jun 2020 08:46:29 -0400 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:32880) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhBjv-00041i-SU for emacs-devel@gnu.org; Fri, 05 Jun 2020 08:46:28 -0400 Original-Received: by mail-wr1-x434.google.com with SMTP id l11so9651284wru.0 for ; Fri, 05 Jun 2020 05:46:27 -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=3AkiFDiSWxF7Eaw5trkdR4MPzdtL94IZsNd0iTDpNDc=; b=fMJgJGyDawlNBzxiUSEMtRY0E7JjV1grnx7Ln1HAHFkGVdTB2mOPDnfk7i5MEGqyHU h6LP98KHwBk8NxuAQMfKvwMuoqSgajNfq07VhPXfTabXQRTMQAmUvPwLNGrn/XWhNOs5 1VHAJBv6SH2bBqvHDExDPmUJ/aaLILjWN35MBo4G2JywIVx/QuH+ePL0bs+NZwJJkYE/ zPGxnffUCrd4HRZax9s71Yl36uEQ9AKlJRSrwdp+to9vrXEWaCnlOTjPwRYiP1NIiGkQ Sxb/CvfF4REHKlYK5I+fAteyKhPHcgKAMZyoOcn0RDeKBpkFp5I2R63o1FojwKR8JKuw iTkg== 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=3AkiFDiSWxF7Eaw5trkdR4MPzdtL94IZsNd0iTDpNDc=; b=Y8NC2n4+NLQfOpfo0WHGIjQO+GFMQv2QmhvwWVfh9rriCMPtsQ5TcNGl/pI24o5RtE Pq5bXE4v5OOGWIeQQRS5DpjNez/jmpTXIHSc+vOCjXxYHgohcYb+ZCQFeDlYOoCO4ihS kNZhJLxm9/xtXR6xncysgrIz/372JhZoVMGit149Y3KYksYv0aTlYXQen0LjAQaSLOgu toZmao6PrbRpCKDa8WZt9x/2rXhQY+j//Ek7cSwTi0p9hINoSSEfHakiBK7Syui9HTNE Ns2U/Uh1tzHribYeF03fFEmgm+iY0D/oH4UBsO/N0TvpMT561h16Z03OnVFtB+s6W88E GmUw== X-Gm-Message-State: AOAM531Z9ZIqYTJe8I+fnt9AQp6wg0hNdeW5Jhw77eex6pn/c0s6/oda oIt3mko7W4duuoq5jx7BFVCtgRIDlEs= X-Google-Smtp-Source: ABdhPJxm4Wa2Hyl0utsPVubTc2VNZ+/XhQMliSIOkPU+cYpoJ0mPkpkBeFz/QwGM9YDOubUmbWA3PQ== X-Received: by 2002:a5d:6b83:: with SMTP id n3mr9392904wrx.395.1591361185901; Fri, 05 Jun 2020 05:46:25 -0700 (PDT) Original-Received: from chametz (this-is-a-tor-node---10.artikel5ev.de. [185.170.114.25]) by smtp.gmail.com with ESMTPSA id b8sm11772058wrm.35.2020.06.05.05.46.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2020 05:46:25 -0700 (PDT) In-Reply-To: <87eeqtiy4x.fsf@tcd.ie> (Basil L. Contovounesios's message of "Fri, 05 Jun 2020 11:51:26 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::434; envelope-from=pipcet@gmail.com; helo=mail-wr1-x434.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:251893 Archived-At: "Basil L. Contovounesios" writes: > Stefan Monnier writes: >>> @@ -202,7 +202,7 @@ The format has been repaired and the variable modified accordingly. >>> You can save the current value through the customize system by >>> either clicking or hitting return " >>> (make-text-button >>> - "here" nil >>> + (copy-sequence "here") nil >>> 'face '(:weight bold :inherit button) >>> 'mouse-face '(:weight normal :background "gray50" :inherit button) >>> 'follow-link t >> >> So, here why do we need to `copy-sequence`? > > To avoid destructively modifying a string literal by placing properties > on it. I think adding a concept of mutability/constness/finality/... could be a great extension of the ELisp language. It would also be a very significant change of that language, perhaps comparable to "true" multi-threading. It would not be a quick bug fix for code that uses (propertize "string" 'a 'b). In particular, I'm not convinced code like that is buggy at all. It's true that it will fail under certain conditions (the string constant is used again in the same function, the function is byte compiled, that sort of thing), and it's true there are better ways of doing that, but is that reason enough to off-handedly ban all such code? I probably don't even know half of it, but there are so many overlapping concepts ("const" in C, "constexpr" in C++, "final" in Java, "const" in JavaScript, "frozen" objects in Python...) that 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. I think it's worth it to experiment with other concepts of mutability, perhaps on a feature branch, but I don't think that's true for a concept that, so far, appears to be "literal strings can't be given text properties unless they already have at least one, in which case you can alter their text properties but not remove them all". I'll take all of that back if I actually see a bug that means Lisp code can cause an Emacs crash (in the C sense of "crash") by mutating literal strings, and that can't easily be fixed in C, and isn't actually a known limitation of the byte compiler. My guess is a concept of immutability won't be very useful if it's just a single bit telling you "this object is immutable": we need to attach more information to it, perhaps going as far as providing special ways of mutating the object rather than simply signalling an information-free error. (So, for example, a vector could be defined in Lisp to coerce all of its entries to nil or t, so we wouldn't need bool vectors anymore). Sorry this got long, but I don't understand the rush to actually commit to what appears to me to be a simplistic model of mutability when we haven't even removed the previous one, which I believe we've outgrown: pure space. (I think we should also get rid of the hash table mutability thing again, but that's another discussion entirely).