From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#40671: [DOC] modify literal objects Date: Mon, 11 May 2020 02:00:15 +0200 Message-ID: <87mu6ftk6o.fsf@web.de> References: <012e8bc3-df4b-3884-4e54-5fe7ef4248cb@cs.ucla.edu> <37a54ac2-da80-ca35-9c01-38c8e12a4b5f@yandex.ru> <9375aaeb-2a9a-b307-c793-0d99328201ea@yandex.ru> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="9362"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 11 02:01:39 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 1jXvt5-0002KW-Aa for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 02:01:39 +0200 Original-Received: from localhost ([::1]:55426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXvt3-0006Eq-MR for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 May 2020 20:01:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48854) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXvsU-0006Ei-GX for bug-gnu-emacs@gnu.org; Sun, 10 May 2020 20:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39167) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXvsU-0005sF-7V for bug-gnu-emacs@gnu.org; Sun, 10 May 2020 20:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jXvsU-0008IV-6M for bug-gnu-emacs@gnu.org; Sun, 10 May 2020 20:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 00:01:02 +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.158915525731876 (code B ref 40671); Mon, 11 May 2020 00:01:02 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 11 May 2020 00:00:57 +0000 Original-Received: from localhost ([127.0.0.1]:50713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXvsO-0008I3-M3 for submit@debbugs.gnu.org; Sun, 10 May 2020 20:00:56 -0400 Original-Received: from mout.web.de ([212.227.17.11]:40605) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXvsN-0008Hl-3y for 40671@debbugs.gnu.org; Sun, 10 May 2020 20:00:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1589155218; bh=0+kBfzhT4vHdSJRftH3CCIfZZxd0Ljy4zDFxHByQKME=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=D3pxhNHfa7RmukVFxp5kHvyOucVnLgc/qSTUX+8386XWAc3JBGocIRv4w37sO5yxG /NG7FJK3G8gJcApUFS4QehtrwyqbRyn5YXWsiNHfefrpoafZKOs7aLhq5wjb8OjmI7 PP7JjSpjSQuV5fykhmlKtcMD81FcSZe7oIkw1zKs= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from drachen.dragon ([88.67.107.170]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MsJSy-1jEcpc01iU-00teHz; Mon, 11 May 2020 02:00:18 +0200 In-Reply-To: <41d69e2e-561f-743a-e1f0-282b2e22b66c@cs.ucla.edu> (Paul Eggert's message of "Sun, 10 May 2020 10:29:21 -0700") X-Provags-ID: V03:K1:Y1IQt57Z9Y01ntGLY/2NUDxm8eHwJ85jOhjuESkYfX7//XpYUpO mu/HgkcHOGjQO45BXwXuCxrG9GGtb0LW7JfdD/9HQdVJ66cewTpBBlnZm/yUok4hjQToX/A kajIGV3GCbJbBz+XES4AsHE7Q98UUnlJuhwLZa+WBepzEPsZGCwWB0+khv/fKFqpd80Yph4 qcl+f4jmGPbvDC96fRMWA== X-UI-Out-Filterresults: notjunk:1;V03:K0:nccpoIj1vTE=:cDHL32XrPwBx7Aj6haf6SG YwBs4/oJKQ3Tn56R4Hex0HPxxdyIaM8JcVmbflu/UdIQLj8GLUao3DBRNNH4CYx+CekZ2R6lL 5nR8sczn6qTtfwAZVFmu/g5KigPpY+jeYkiZxhvSRaIhGQzdgPEegZcOCMYjzIePG4VTUloQl 4YYhveTxw/anTu6j6d4e+9ghCm9xncoXiYOE+3q/1qSvyejngPDqe24C/TFTRiYATm0KuhgGF Bf1MoPLxrxmdMAi3leDmDEtgS7TjoWjX3P05Kiy1wu4fNtoxUJRppFvgycAu+Cj/95zBkgj8B oSO2ZdJ55PltgmVU6KkF2H2MMUhq7RL/TMp0wonbSFp4/G1j7u4PRlE72UqYsaF3TLeKc43lt j2sE1aPN6ojyxVAVk6FdnO/6AbeuIg+3S9qw/PbJV5qlrdSTF92yG0hyc5nHERY71b8MkrKSK kYd6Hi8x+ZmQvC5M8qSsoHp1OBVcn4Z9cENkTDRSAwclmB1XJ/kidYjb0CguTqWplOZSOAtoM Z3ZoZ4lU0TkGi82MH83aBdwcj8toOmKkaE7ZIpUhUWqDTmdMnE/aRUaUKVMDhm/f8/oV0QNfR Uz8ZU382Ch2TgzMcZJsloa/jhZ7o9d9Wc0GlQgSrr9khMN29n8W3z4+/ilWXjXGSt503UAukE YTIntK13S1p25w29qb2e4WAVsHBxQz+u6Y5bgI0BCU3xvV4cXLwiqXKoidh7gCeTv93yzIlm3 j13Gea/XlJ7w93746fxBZjNJhOWwNgPKhYUOeWIgkTumJAi6SC2UYkUBaQIyHgrVWeMjTYQP 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:180035 Archived-At: Paul Eggert writes: > I'm attaching two patches. Thanks for the continued work on this, I appreciate the improvements and the general direction. I may have missed parts of the discussion recently, sorry if some comments are unsubstantial. So, a few questions about the patches: > + 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, strings, and symbols. 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}. Is this a good statement? The string read syntax, and the syntax for lists makes it easy to make such objects part of a program. But all classes of objects you call mutable can end up as part of a program. Are there any classes of "types" where all members are always mutable? Second point: you mix up objects vs. object evaluation. For conses you speak about the objects, for symbols about the binding (i.e. the result of the evaluation). Conses can also be evaluated (most programs are conses), but that's surely not what you want to describe. I would not say symbols are mutable. Symbols are constant AFAICT, their bindings are not (variables are not constant). > + A mutable object stops being mutable if it is part of an expression > +that is evaluated. For example: FWIW, I would feel better about the word "mutable" if you would introduce the term like "safely mutable", and then say that we call it just "mutable" in the following sections because this is shorter. Drew mentioned his dislike for the term "safe" AFAIR but I think "my Emacs won't crash if I follow this" vs. "it can crash" describes some kind of safety. Ignore if this comment is irrelevant because this is already done or treated otherwise. > + When the same value appears multiple times in a program, the Lisp > +interpreter might save time or space by reusing existing values or > +their components. For example, @code{(eq "abc" "abc")} returns I think we call "values" what evaluation of expressions yields, so values don't appear in a program (to be read). I don't know the backgrounds and when this can happen. Is it always the interpreter that does this mapping? "Same syntax" is not good as well: (eq (list 1 2 3) (list 1 2 3)) doesn't provoke the pitfall you warn about, but your wording doesn't make clear why the one case is ok and the other is not. Maybe it's again as simple as saying something about objects as being part of a program? Thanks again, Michael.