From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#40671: [DOC] modify literal objects Date: Sun, 19 Apr 2020 15:24:24 -0700 (PDT) Message-ID: <566aa1bf-444d-4cff-aed8-5b83fcd60107@default> References: <87v9lzmdrw.fsf@laposte.net> <57532862-f6ec-84b6-13af-8a8985366ff0@cs.ucla.edu> <127084e8-c62a-ec8c-5d40-8c4280861519@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="127584"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Kevin Vigouroux , 40671@debbugs.gnu.org To: Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 20 00:25:16 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1jQINH-000X5e-KL for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Apr 2020 00:25:15 +0200 Original-Received: from localhost ([::1]:48256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQING-0007eQ-KS for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Apr 2020 18:25:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36432 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQIN5-0007cW-AK for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 18:25:03 -0400 Original-Received: from Debian-exim by eggs1p.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQIN4-0005KR-De for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 18:25:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34606) by eggs1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQIN4-0005KK-0N for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 18:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jQIN3-0002RB-QY for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 18:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 22:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40671 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873350929348 (code B ref 40671); Sun, 19 Apr 2020 22:25:01 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 22:24:52 +0000 Original-Received: from localhost ([127.0.0.1]:46152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQIMt-0002Qi-JF for submit@debbugs.gnu.org; Sun, 19 Apr 2020 18:24:51 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:54746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQIMs-0002QW-MZ for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 18:24:51 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03JMIQmC077687; Sun, 19 Apr 2020 22:24:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=c1sMyz4M9Ll3kdLCjFdqlau0fHhU6WzUnEHzmrhJPWQ=; b=H8b+cMSIIqfB9BJhpOvwdo+//p87Jmh+Lb4V4Cwsvu/FgkmhnOYwCBgntN9SZLXe7pf3 YOS+dcx5XXgiUu3xdXniHobarmE3gL4wRq+50gkA8+7TLWY9KcGU2GTe8bh+yRJZz+YQ R3yPwjZh4prQ4sNcTvzny8jHLS+jHXv4KCdO3/GEatDwLRtSfe1yn6kjbrJrBMCAOpeE NGrorkToV8FqefEcAwk4nxBP9WsMSAwp7DZzA47MZWmHO/5nTFskMo8+cOeYrKOJUrTk 47kwk+/kR7dnOGje1mJ9PgiHvfmbFPtp7Pwp051oPm/bB8/NLBxcouBcPNIE7w0gtqai jQ== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 30fsgkm8xh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 19 Apr 2020 22:24:34 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03JMHRXh158408; Sun, 19 Apr 2020 22:24:33 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 30gb3p23bb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 19 Apr 2020 22:24:33 +0000 Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03JMOPH2028489; Sun, 19 Apr 2020 22:24:25 GMT In-Reply-To: <127084e8-c62a-ec8c-5d40-8c4280861519@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4966.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 adultscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004190191 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 clxscore=1015 spamscore=0 bulkscore=0 phishscore=0 suspectscore=0 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004190191 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:178677 Archived-At: > >> distinguish between constant objects (which the > >> program should not change) and mutable objects > >> (which the program can change). > > > > That's just not what "constant" means. >=20 > What does "constant" mean to you? It's not clear. Something that remains constant. You simply can't change it - impossible. The doc for `defconst' makes clear that it does _not_ define a constant, for example. In what way is what it defines a variable and not a constant? The fact that you _can_ change it. If you can change something then it's not a constant. The problem is that you're using "constant", NOT for something that CANNOT be changed, but for something that you SHOULD NOT try to change. Not the same thing. > > And I suspect that your _uses_ of _not_ "mutable" > > will still be for things that we really want to say > > you probably _should not_ change, and not that > > you _cannot_ change them. >=20 > Your suspicion is correct. So my suspicion is correct: you're misusing "not mutable" to mean, not something that can't be changed but something that probably shouldn't be changed. See above: not mutable =3D constant. > In the current emacs-27 documentation, "mutable" > means you can change the object, That contradicts your statement of my suspicion being correct. If "mutable" means you can change it (which is truly what it means) then "not mutable" means you can't change it. It doesn't mean only that you probably shouldn't change it. It's the same point. mutable =3D changeable, not mutable =3D constant (not changeable). You're using "should not" in place of "cannot". Which means you're also using "no reason not to" in place of "can". And the gotcha is precisely that in some cases where you _can_, you probably _should not_. > "constant" means you should not change it. Again, a misuse. "Constant" means truly not mutable, i.e., you _cannot_ change it. The message you're giving is backward, or at least unclear. Don't say "constant". Say "don't try to change it". Not because you can't change it (not because it's constant), but because the code won't necessarily do what you expect - it might change as you think, or it might not. That's really the point, I think. > It's intended to be documentation that is simple > and consistent IMO, it's neither. Simple is to just say that you _cannot depend on_ `quote' (and some other constructs, no doubt) returning a new object, especially in code that looks like it would be evaluated multiple times. And since you can't depend on this, don't. That's the simple message: "don't do that, because it might not do what you expect" (when byte-compiled, in particular). It might (IMO) be helpful to explain that for interpreted Elisp source code what you see is what you get (is that always true?), but the same is not true for byte-compiled code. And `(quote (A B))' is a good example. We probably already say something like that (?) in other contexts: byte-compiled code may change order of evaluation or the number of times a subexpression gets evaluated - for optimization. You can't count on byte-code acting just like as source code from which it's compiled would suggest. > what they shouldn't do (try to change a constant) No one tries to change a constant. The problem - the gotcha - is that it's not always obvious when your code is trying to change a constant. In particular (but not only), beware of quoted lists. > Of course the documentation could have a more-complex > discussion of the various ways that an object could > be "constant". And somewhere in the doc that might be helpful, but only if the particular cases documented are cases we intend to keep as such. It can happen that we instead decide to keep that in the dark ("just" implementation), and we just document that whether XYZ is such a case is "undefined" - so don't count on it acting as a constant or not as a constant. > The object could be in read-only memory enforced by > the hardware and operating system, As I said earlier, there's no need to say something's a constant if it's actually enforced as a constant, in the sense that an error is raised if you try to modify it. The only cases that are problematic are those where you can think your code modifies something (anew) when in fact it might not. That's the case we're talking about wrt quoted list structure.=20 > > And places where you will likely say there's no > > reason you _shouldn't_ change something will > > likely give the impression that this is because > > it is "mutable", and give the impression that > > there's no reason you shouldn't change anything > > that you _can_ change. This can give the > > impression that if you _can_ change something > > (the real meaning of "mutable") then there's no > > reason you shouldn't change it. >=20 > I'm not following. By mischaracterizing not mutable as "should not be changed" (instead of "cannot be changed"), you can give the false impression that the opposite is true: if something is mutable then there's no reason you shouldn't change it. Not that the latter follows logically from the former, but by twisting the meaning of "mutable" all bets in understanding are off.