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.bugs Subject: bug#40671: [DOC] modify literal objects Date: Sun, 19 Apr 2020 14:16:35 -0700 Organization: UCLA Computer Science Department Message-ID: <127084e8-c62a-ec8c-5d40-8c4280861519@cs.ucla.edu> References: <87v9lzmdrw.fsf@laposte.net> <57532862-f6ec-84b6-13af-8a8985366ff0@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="112037"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Kevin Vigouroux , 40671@debbugs.gnu.org To: Drew Adams , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 19 23:17:14 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 1jQHJS-000T2K-LU for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Apr 2020 23:17:14 +0200 Original-Received: from localhost ([::1]:47824 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQHJR-00032C-CG for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Apr 2020 17:17:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51638 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQHJG-00030Y-Tj for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 17:17:03 -0400 Original-Received: from Debian-exim by eggs1p.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQHJG-0006Ee-A4 for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 17:17:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34566) by eggs1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQHJF-0006ED-S5 for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 17:17:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jQHJF-0000p4-Mq for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 17:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 21:17: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.15873310053136 (code B ref 40671); Sun, 19 Apr 2020 21:17:01 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 21:16:45 +0000 Original-Received: from localhost ([127.0.0.1]:46112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQHIy-0000oW-LW for submit@debbugs.gnu.org; Sun, 19 Apr 2020 17:16:44 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36126) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQHIw-0000oD-Kd for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 17:16:43 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5F07E160065; Sun, 19 Apr 2020 14:16:36 -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 z4DnxRtYayoh; Sun, 19 Apr 2020 14:16:35 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 92FAF16008E; Sun, 19 Apr 2020 14:16:35 -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 DC_eGzHtC7iJ; Sun, 19 Apr 2020 14:16:35 -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 63018160065; Sun, 19 Apr 2020 14:16:35 -0700 (PDT) In-Reply-To: Content-Language: en-US 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:178674 Archived-At: On 4/19/20 2:01 PM, Drew Adams wrote: >> 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. What does "constant" mean to you? It's not clear. > 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. Your suspicion is correct. In the current emacs-27 documentation, "mutable" means you can change the object, "constant" means you should not change it. It's intended to be documentation that is simple and consistent and tells programmers what they can do without worrying (change a mutable object), and what they shouldn't do (try to change a constant). Of course the documentation could have a more-complex discussion of the various ways that an object could be "constant". The object could be in read-only memory enforced by the hardware and operating system, or there could be a run-time check by the Emacs interpreter, or there could be no check at all and you can change the constant with the program behaving erratically afterwards, or there are other possibilities. If you'd like to add text along those lines to the new section "Constants and Mutability" please feel free to suggest something. The point is to make that section useful for Emacs Lisp programmers, after all. > 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. I'm not following. Even if I've created an object with the 'cons' function there may be very good pragmatic reasons for me to not invoke setcar and setcdr on it, as otherwise my program's actions will be scrambled. However, from the Emacs lisp point of view such a cons is still mutable. If you propose specific text for the manual, no doubt your point will become clearer.