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: Sat, 16 May 2020 18:28:18 -0700 Organization: UCLA Computer Science Department Message-ID: References: <7fe0574a-62ae-94fb-2e55-1a69de6ce828@cs.ucla.edu> <91857438-f44a-90f4-dfe2-a32224ba3994@yandex.ru> <880dc34b-46a9-0149-3c6e-0a951a70125d@cs.ucla.edu> <9c46b93e-a855-0be0-7ab0-50cb8c5cd74d@yandex.ru> <48e90f87-1519-9101-d54b-4bfd81a0c936@yandex.ru> <252d6368-ddea-2f41-b53f-cd927ebc3d1d@cs.ucla.edu> <43d93102-d361-f64b-971b-909418b89fca@yandex.ru> <2ca64f28-1255-4135-6e45-0f0e12b9e72d@cs.ucla.edu> <0c7570cb-bf52-a617-bf54-27a47c54e04a@cs.ucla.edu> <04298f7d-f2c0-5186-57d3-522e3d886166@cs.ucla.edu> <88af48c6-bc39-6ab0-59ec-7d537f2d375d@yandex.ru> <41d69e2e-561f-743a-e1f0-282b2e22b66c@cs.ucla.edu> <4ba236ce-ade0-5cd1-656a-f2df46d67d5f@cs.ucla.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3175E7D713E251357BAE1EB7" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="123657"; 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: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Richard Stallman To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 17 03:29:54 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 1ja87m-000W5T-FS for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 May 2020 03:29:54 +0200 Original-Received: from localhost ([::1]:48746 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ja87l-0007Iy-Hw for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 May 2020 21:29:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60660) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ja86v-0006V7-V0 for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 21:29:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58668) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ja86v-0006Bl-Lp for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 21:29:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ja86v-000418-IQ for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 21:29: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, 17 May 2020 01:29: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.158967890715401 (code B ref 40671); Sun, 17 May 2020 01:29:01 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 17 May 2020 01:28:27 +0000 Original-Received: from localhost ([127.0.0.1]:41981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ja86N-00040L-2E for submit@debbugs.gnu.org; Sat, 16 May 2020 21:28:27 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ja86L-000408-Rn for 40671@debbugs.gnu.org; Sat, 16 May 2020 21:28:26 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 42044160052; Sat, 16 May 2020 18:28:20 -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 MKzQEDZtSpLI; Sat, 16 May 2020 18:28:19 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0B8561600DA; Sat, 16 May 2020 18:28:19 -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 piB0S_fPAPkF; Sat, 16 May 2020 18:28:18 -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 988C9160052; Sat, 16 May 2020 18:28:18 -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 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:180425 Archived-At: This is a multi-part message in MIME format. --------------3175E7D713E251357BAE1EB7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/11/20 6:59 PM, Dmitry Gutov wrote: > I think that's exactly what a "constraint" means: something that is enforced. Not necessarily. In some software systems constraints are not enforced. (Use Google to search for "unenforced constraints", which can be quite the thing in the database world.) But I am straying from the documentation issue. > The symbol-name example? I'm not sure it's really important to > warn about this one in particular. OK, but then you also write: > When one tries to > describe "unsafe" things to do, they don't just give a few examples, they > usually try to cover all cases. ... and symbol-name is one of the cases. As far as the bigger project (cover all the cases) goes, I don't know how feasible that would be. I suppose someone could take that on as a further task. In the attached patch I did add one more example, of calling the copy-sequence function, but there would be lots more examples where that came from. > Inventing a name for such values doesn't help if the user doesn't have enough > knowledge to avoid all members of this set. Or is "part of an expression that is > evaluated" after all the test we'll be teaching? No, it's not the only way that something can be a constant. This is why the (symbol-name 'cons) example is relevant: it yields a string that has never been "part of an expression that is evaluated". > By the way, I have read last two paragraphs of that section now. C and > "constants" are still there. It's appropriate to talk about constants in the footnote that mentions languages that have constants. And the footnote is helpful, because it documents the core issue that prompted this long thread: different languages/traditions mean different things by the word "constant" and/or "immutable", and the footnote makes it clear that the documentation's "objects that should not be changed" follows the Common Lisp / C tradition, not the Python / JavaScript tradition. That being said, it'd be helpful if the footnote mentions both "constants" and "immutable objects" if only to remind readers of relevant buzzwords. So I did that in the attached patch. > I'm curious to see the discussion about actually making this error at runtime in > one of the next Emacs version. Me too. That's for a later thread, one that I'd like to get rolling instead of worrying about the minor details in the current doc. To help get things rolling I installed the patch that I proposed earlier, followed by the attached minor patch that attempt to address the abovementioned issues. I plan to look at improving the runtime checking next. --------------3175E7D713E251357BAE1EB7 Content-Type: text/x-patch; charset=UTF-8; name="0001-Minor-fixups-for-mutability-doc.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Minor-fixups-for-mutability-doc.patch" >From b48ab743a861b8041518ce7459bde51c3dd02ee0 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 16 May 2020 18:16:23 -0700 Subject: [PATCH] Minor fixups for mutability doc * doc/lispref/objects.texi (Mutability): Minor fixups in response to a comment by Dmitry Gutov (Bug#40671#477). --- doc/lispref/objects.texi | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 136213ad66..5c5f89eb43 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2381,7 +2381,7 @@ that for two strings to be equal, they have the same text properties. Some Lisp objects should never change. For example, the Lisp expression @code{"aaa"} yields a string, but you should not change -its contents. Indeed, some objects cannot be changed; for example, +its contents. And some objects cannot be changed; for example, although you can create a new number by calculating one, Lisp provides no operation to change the value of an existing number. @@ -2393,11 +2393,10 @@ point to somewhere else. Although numbers never change and all markers are mutable, some types have members some of which are mutable and others not. These types include conses, vectors, and strings. For example, -although @code{"aaa"} yields a string that should not be changed, -@code{(make-string 3 ?a)} yields a mutable string that can be -changed via later calls to @code{aset}. Another example: -@code{(symbol-name 'cons)} yields a string @code{"cons"} that should -not be changed. +although @code{"cons"} and @code{(symbol-name 'cons)} both yield +strings that should not be changed, @code{(copy-sequence "cons")} and +@code{(make-string 3 ?a)} both yield mutable strings that can be +changed via later calls to @code{aset}. A mutable object stops being mutable if it is part of an expression that is evaluated. For example: @@ -2419,9 +2418,9 @@ becomes mutable afterwards. changed, the resulting behavior is undefined: the Lisp interpreter might signal an error, or it might crash or behave unpredictably in other ways.@footnote{This is the behavior specified for languages like -Common Lisp and C, and it differs from the behavior of languages like +Common Lisp and C for constants, and this differs from languages like JavaScript and Python where an interpreter is required to signal an -error if a program attempts to change a constant. Ideally the Emacs +error if a program attempts to change an immutable object. Ideally the Emacs Lisp interpreter will evolve in latter direction.} When similar constants occur as parts of a program, the Lisp -- 2.17.1 --------------3175E7D713E251357BAE1EB7--