From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Kevin Vigouroux Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Apr 2020 20:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 40671 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 40671@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.158706957724731 (code B ref -1); Thu, 16 Apr 2020 20:40:02 +0000 Received: (at submit) by debbugs.gnu.org; 16 Apr 2020 20:39:37 +0000 Received: from localhost ([127.0.0.1]:39448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPBIO-0006Qo-7a for submit@debbugs.gnu.org; Thu, 16 Apr 2020 16:39:37 -0400 Received: from lists.gnu.org ([209.51.188.17]:49510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPABO-0004ek-Jr for submit@debbugs.gnu.org; Thu, 16 Apr 2020 15:28:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51971) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPABM-0002Lt-Tn for bug-gnu-emacs@gnu.org; Thu, 16 Apr 2020 15:28:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_50,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,SPOOFED_FREEMAIL,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jPABJ-0001rO-DB for bug-gnu-emacs@gnu.org; Thu, 16 Apr 2020 15:28:14 -0400 Received: from smtpoutz22.laposte.net ([194.117.213.97]:37395 helo=smtp.laposte.net) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jPABI-0001mD-UF for bug-gnu-emacs@gnu.org; Thu, 16 Apr 2020 15:28:13 -0400 Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout010 (Postfix) with ESMTP id 89DA84B241E for ; Thu, 16 Apr 2020 21:28:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=laposte.net; s=mail0; t=1587065284; bh=q8KfU+TIs9FYwEGP4OnsPMQdzi+dztG0Ta4pxZLbg78=; h=From:To:Subject:Date; b=YG+Jjg/15ql/9awHgu5xwqFrKWiNHQQt5X3m9L4gJ+CJ5SGNOJlkyPICpkvlOm7sT JXu5psFJtMUFkwMyERt5gK/GvlVw7ogsaXmE6YPO+e45286D5DFfwOz4PNjdBdjPzm t4J9jwHLSElAcfxiWTpDF9H9Nn8+AgGtGR9KinXiTd8H5rKwsbeuu9Y+G44UrDzV6C dhaRstWjgDF3Wb0MW9RQ3/hXTBn/Au9NlJ5YQE2sjhsFYNTroggtPqoqQdewFGFVUz aC99I22iOA8MkQGnTYR85uzPg2XCNnJ5072uFphaJbCBNTj/G5dsIzxq2wEeXzvgUS 2AOXF93yIlVlQ== Received: from outgoing-mail.laposte.net (unknown [10.94.128.98]) by lpn-prd-vrout010 (Postfix) with ESMTP id 842114B241C for ; Thu, 16 Apr 2020 21:28:04 +0200 (CEST) Received: from outgoing-mail.laposte.net (localhost.localdomain [127.0.0.1]) by mlpnf0119.laposte.net (SMTP Server) with ESMTP id 4938QD3YZpz1qqj0 for ; Thu, 16 Apr 2020 21:28:04 +0200 (CEST) X-ppbforward: {"queueID":"4938QD3YZpz1qqj0","server":"mlpnf0119"} X-mail-filterd: 0.4.0.2 X-mail-filterd: 0.4.0.2 X-ppbforward: {"queueID":"4938QD27Vvz1qqhy","server":"mlpnf0119"} X-lpn-spamrating: 40 X-lpn-spamlevel: not-spam X-lpn-spamcause: OK, (0)(0000)gggruggvucftvghtrhhoucdtuddrgeduhedrfeehgddufeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecunfetrffquffvgfdpqfgfvfdpggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkgggtsehttdertddttddtnecuhfhrohhmpefmvghvihhnucggihhgohhurhhouhiguceokhgvrdhvihhgohhurhhouhigsehlrghpohhsthgvrdhnvghtqeenucffohhmrghinhepshhtrggtkhgvgigthhgrnhhgvgdrtghomhenucfkphepledtrdefvddrudduiedrfedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepsghluhgvmhgrnhdpihhnvghtpeeltddrfedvrdduudeirdeftddpmhgrihhlfhhrohhmpehkvgdrvhhighhouhhrohhugieslhgrphhoshhtvgdrnhgvthdprhgtphhtthhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnhhurdhorhhg X-lpn-mailing: LEGIT Received: from blueman (arennes-256-1-117-30.w90-32.abo.wanadoo.fr [90.32.116.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mlpnf0119.laposte.net (SMTP Server) with ESMTPSA id 4938QD27Vvz1qqhy for ; Thu, 16 Apr 2020 21:28:04 +0200 (CEST) From: Kevin Vigouroux Date: Thu, 16 Apr 2020 21:28:03 +0200 Message-ID: <87v9lzmdrw.fsf@laposte.net> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 194.117.213.97 X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello! The Emacs Lisp manual often gives the impression that the user can modify literal lists (e.g. 5.6.1 Altering List Elements with `setcar`). LISP> (setq x '(1 2)) (1 2) LISP> (setcar x 4) LISP> x (4 2) Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: stackexchange.com] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [209.51.188.17 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ke.vigouroux[at]laposte.net) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/Why?s=mfrom; id=ke.vigouroux%40laposte.net; ip=209.51.188.17; r=debbugs.gnu.org] 2.0 SPOOFED_FREEMAIL No description available. X-Mailman-Approved-At: Thu, 16 Apr 2020 16:39:35 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hello! The Emacs Lisp manual often gives the impression that the user can modify literal lists (e.g. 5.6.1 Altering List Elements with `setcar`). LISP> (setq x '(1 2)) (1 2) LISP> (setcar x 4) LISP> x (4 2) However, it is also mentioned that one should not modify the literal objects because of the byte compilation (c.f. 2.7 Equality Predicate). Can we modify literal objects? See Also: https://emacs.stackexchange.com/questions/45820/when-to-use-quote-for-lists-modifying-quoted-lists-in-elisp https://emacs.stackexchange.com/questions/57806/which-lisp-objects-are-byte-compiled Best regards, Kevin Vigouroux. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects References: <87v9lzmdrw.fsf@laposte.net> In-Reply-To: <87v9lzmdrw.fsf@laposte.net> Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Apr 2020 16:11: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: To: 40671@debbugs.gnu.org Cc: Kevin Vigouroux Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15871398027582 (code B ref 40671); Fri, 17 Apr 2020 16:11:02 +0000 Received: (at 40671) by debbugs.gnu.org; 17 Apr 2020 16:10:02 +0000 Received: from localhost ([127.0.0.1]:41570 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPTZ3-0001y4-PF for submit@debbugs.gnu.org; Fri, 17 Apr 2020 12:10:02 -0400 Received: from mail1441c50.megamailservers.eu ([91.136.14.41]:42158 helo=mail264c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPTZ2-0001xm-F6 for 40671@debbugs.gnu.org; Fri, 17 Apr 2020 12:10:01 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1587139793; bh=2yNaT8WR9gMD10+L3hiR9T+FkgCiC7eqKVBUUarqMQE=; h=From:Subject:Date:Cc:To:From; b=HlSP9Lli4aX+NDP9Nj4ezk7RwqQZSUUqbpU8H9C51SVbqG3nXM6SYNamvssjIDI0r kGxiNxF6WUSPmfst++WA3kE93dtE64XQrJdtcKxdC9T/SP0XnLhZ0MzoFjvNkSv2N8 dik/tKtvnF0H73QWhVrWBABzDMgudneUmw55Fz+U= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail264c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 03HG9paT006038; Fri, 17 Apr 2020 16:09:53 +0000 From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Message-Id: <0B653323-49E1-4AC7-A85B-18346D220585@acm.org> Date: Fri, 17 Apr 2020 18:09:51 +0200 X-Mailer: Apple Mail (2.3445.104.14) X-CTCH-RefID: str=0001.0A782F22.5E99D4A1.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=PPNxBsiC c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=08160T5Cf-sCvJ5efqMA:9 a=CjuIK1q_8ugA:10 a=pHzHmUro8NiASowvMSCR:22 a=nt3jZW36AmriUCFCBwmW:22 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >Can we modify literal objects? No, and the manual should do a much better job at explaining this. At the very least it should not promulgate Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: megamailservers.eu] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >Can we modify literal objects?=20 No, and the manual should do a much better job at explaining this. At = the very least it should not promulgate=20= From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Apr 2020 16:38: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: To: 40671@debbugs.gnu.org Cc: Kevin Vigouroux Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158714145718151 (code B ref 40671); Fri, 17 Apr 2020 16:38:01 +0000 Received: (at 40671) by debbugs.gnu.org; 17 Apr 2020 16:37:37 +0000 Received: from localhost ([127.0.0.1]:41585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPTzl-0004ic-B7 for submit@debbugs.gnu.org; Fri, 17 Apr 2020 12:37:37 -0400 Received: from mail233c50.megamailservers.eu ([91.136.10.243]:45480 helo=mail37c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPTzg-0004iJ-4a; Fri, 17 Apr 2020 12:37:35 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1587141449; bh=WKgN6ktHg8Mce3bVFVHx/1+TAEVmTviLzRzCP8ZG4m8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=SicNiA/w9wneOSbWPsrusV9HVfjR9xq1eEevr/C2kz9IAg7gZwNT1HX9X5WfEDpJS gZ1HPVr2zdeaoZrZEgWvO22OlQ6iMqDTm5+MI/2XV+LnroGPW8FFb/4YGE1QuEy4Hn puyN37LPTsGhUYtTVYeXzjesr5WtwDLRH7kVTE08= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail37c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 03HGbNPv024341; Fri, 17 Apr 2020 16:37:27 +0000 Content-Type: multipart/mixed; boundary="Apple-Mail=_5781C227-1A23-46FD-9E9D-ED3BE42938E6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <0B653323-49E1-4AC7-A85B-18346D220585@acm.org> Date: Fri, 17 Apr 2020 18:37:23 +0200 Message-Id: References: <0B653323-49E1-4AC7-A85B-18346D220585@acm.org> X-Mailer: Apple Mail (2.3445.104.14) X-CTCH-RefID: str=0001.0A782F22.5E99DB18.0050, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=bJNo382Z c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=M51BFTxLslgA:10 a=08160T5Cf-sCvJ5efqMA:9 a=CjuIK1q_8ugA:10 a=WTIvEUZ3qfsVv6ZZjfcA:9 a=B2y7HmGcmWMA:10 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 40671 patch stop [Sorry about the truncated message.] > Can we modify literal objects? Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: megamailservers.eu] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --Apple-Mail=_5781C227-1A23-46FD-9E9D-ED3BE42938E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii tags 40671 patch stop [Sorry about the truncated message.] > Can we modify literal objects?=20 No, and the manual should do a much better job at explaining this. At = the very least it should not promulgate bad ideas by including mutation = of literals in example code. Patch attached, suggested for emacs-27. We should not even try to show what happens when the user breaks the = rule, because it is undefined. --Apple-Mail=_5781C227-1A23-46FD-9E9D-ED3BE42938E6 Content-Disposition: attachment; filename=0001-Don-t-mutate-literals-in-manual-examples-bug-40671.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="0001-Don-t-mutate-literals-in-manual-examples-bug-40671.patch" Content-Transfer-Encoding: quoted-printable =46rom=209801ee1b12574f8b1b50ba5b76b7ee41a7fb8bc4=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20= =0ADate:=20Fri,=2017=20Apr=202020=2018:00:34=20+0200=0A= Subject:=20[PATCH]=20Don't=20mutate=20literals=20in=20manual=20examples=20= (bug#40671)=0A=0A*=20doc/lispref/edebug.texi=20(Printing=20in=20Edebug):=0A= *=20doc/lispref/keymaps.texi=20(Changing=20Key=20Bindings):=0A*=20= doc/lispref/lists.texi=20(Setcar,=20Setcdr,=20Rearrangement,=20Sets=20= And=20Lists)=0A(Association=20Lists,=20Plist=20Access):=0A*=20= doc/lispref/sequences.texi=20(Sequence=20Functions,=20Array=20= Functions):=0A*=20doc/lispref/strings.texi=20(Text=20Comparison):=0A= Rewrite=20example=20code=20to=20not=20mutate=20constant=20(literal)=20= lists,=20vectors=0Aor=20strings.=20=20Noticed=20by=20Kevin=20Vigouroux.=0A= ---=0A=20doc/lispref/edebug.texi=20=20=20=20|=20=202=20+-=0A=20= doc/lispref/keymaps.texi=20=20=20|=20=208=20++---=0A=20= doc/lispref/lists.texi=20=20=20=20=20|=2062=20= +++++++++-----------------------------=0A=20doc/lispref/sequences.texi=20= |=2026=20++++++++--------=0A=20doc/lispref/strings.texi=20=20=20|=20=204=20= +--=0A=205=20files=20changed,=2034=20insertions(+),=2068=20deletions(-)=0A= =0Adiff=20--git=20a/doc/lispref/edebug.texi=20b/doc/lispref/edebug.texi=0A= index=20cfef5c12d1..5970e7cf80=20100644=0A---=20= a/doc/lispref/edebug.texi=0A+++=20b/doc/lispref/edebug.texi=0A@@=20= -858,7=20+858,7=20@@=20Printing=20in=20Edebug=0A=20=20=20Here=20is=20an=20= example=20of=20code=20that=20creates=20a=20circular=20structure:=0A=20=0A= =20@example=0A-(setq=20a=20'(x=20y))=0A+(setq=20a=20(list=20'x=20'y))=0A=20= (setcar=20a=20a)=0A=20@end=20example=0A=20=0Adiff=20--git=20= a/doc/lispref/keymaps.texi=20b/doc/lispref/keymaps.texi=0Aindex=20= 2c90d208c0..fd207a184e=20100644=0A---=20a/doc/lispref/keymaps.texi=0A+++=20= b/doc/lispref/keymaps.texi=0A@@=20-1441,10=20+1441,10=20@@=20Changing=20= Key=20Bindings=0A=20=0A=20@smallexample=0A=20@group=0A-(setq=20map=20= '(keymap=0A-=20=20=20=20=20=20=20=20=20=20=20=20(?1=20.=20olddef-1)=0A-=20= =20=20=20=20=20=20=20=20=20=20=20(?2=20.=20olddef-2)=0A-=20=20=20=20=20=20= =20=20=20=20=20=20(?3=20.=20olddef-1)))=0A+(setq=20map=20(list=20'keymap=0A= +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(cons=20?1=20'olddef-1)=0A= +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(cons=20?2=20'olddef-2)=0A= +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(cons=20?3=20= 'olddef-1)))=0A=20@result{}=20(keymap=20(49=20.=20olddef-1)=20(50=20.=20= olddef-2)=20(51=20.=20olddef-1))=0A=20@end=20group=0A=20=0Adiff=20--git=20= a/doc/lispref/lists.texi=20b/doc/lispref/lists.texi=0Aindex=20= 27fa5385e3..d1a12e9819=20100644=0A---=20a/doc/lispref/lists.texi=0A+++=20= b/doc/lispref/lists.texi=0A@@=20-906,7=20+906,7=20@@=20Setcar=0A=20=0A=20= @example=0A=20@group=0A-(setq=20x=20'(1=202))=0A+(setq=20x=20(list=201=20= 2))=0A=20=20=20=20=20=20@result{}=20(1=202)=0A=20@end=20group=0A=20= @group=0A@@=20-927,7=20+927,7=20@@=20Setcar=0A=20@example=0A=20@group=0A=20= ;;=20@r{Create=20two=20lists=20that=20are=20partly=20shared.}=0A-(setq=20= x1=20'(a=20b=20c))=0A+(setq=20x1=20(list=20'a=20'b=20'c))=0A=20=20=20=20=20= =20@result{}=20(a=20b=20c)=0A=20(setq=20x2=20(cons=20'z=20(cdr=20x1)))=0A= =20=20=20=20=20=20@result{}=20(z=20b=20c)=0A@@=20-1017,7=20+1017,7=20@@=20= Setcdr=0A=20=0A=20@example=0A=20@group=0A-(setq=20x=20'(1=202=203))=0A= +(setq=20x=20(list=201=202=203))=0A=20=20=20=20=20=20@result{}=20(1=202=20= 3)=0A=20@end=20group=0A=20@group=0A@@=20-1037,7=20+1037,7=20@@=20Setcdr=0A= =20=0A=20@example=0A=20@group=0A-(setq=20x1=20'(a=20b=20c))=0A+(setq=20= x1=20(list=20'a=20'b=20'c))=0A=20=20=20=20=20=20@result{}=20(a=20b=20c)=0A= =20(setcdr=20x1=20(cdr=20(cdr=20x1)))=0A=20=20=20=20=20=20@result{}=20= (c)=0A@@=20-1069,7=20+1069,7=20@@=20Setcdr=0A=20=0A=20@example=0A=20= @group=0A-(setq=20x1=20'(a=20b=20c))=0A+(setq=20x1=20(list=20'a=20'b=20= 'c))=0A=20=20=20=20=20=20@result{}=20(a=20b=20c)=0A=20(setcdr=20x1=20= (cons=20'd=20(cdr=20x1)))=0A=20=20=20=20=20=20@result{}=20(d=20b=20c)=0A= @@=20-1130,7=20+1130,7=20@@=20Rearrangement=0A=20=0A=20@example=0A=20= @group=0A-(setq=20x=20'(1=202=203))=0A+(setq=20x=20(list=201=202=203))=0A= =20=20=20=20=20=20@result{}=20(1=202=203)=0A=20@end=20group=0A=20@group=0A= @@=20-1150,7=20+1150,7=20@@=20Rearrangement=0A=20=0A=20@example=0A=20= @group=0A-(setq=20x=20'(1=202=203))=0A+(setq=20x=20(list=201=202=203))=0A= =20=20=20=20=20=20@result{}=20(1=202=203)=0A=20@end=20group=0A=20@group=0A= @@=20-1163,41=20+1163,7=20@@=20Rearrangement=0A=20@end=20group=0A=20@end=20= example=0A=20=0A-However,=20the=20other=20arguments=20(all=20but=20the=20= last)=20must=20be=20lists.=0A-=0A-A=20common=20pitfall=20is=20to=20use=20= a=20quoted=20constant=20list=20as=20a=20non-last=0A-argument=20to=20= @code{nconc}.=20=20If=20you=20do=20this,=20your=20program=20will=20= change=0A-each=20time=20you=20run=20it!=20=20Here=20is=20what=20happens:=0A= -=0A-@smallexample=0A-@group=0A-(defun=20add-foo=20(x)=20=20=20=20=20=20=20= =20=20=20=20=20;=20@r{We=20want=20this=20function=20to=20add}=0A-=20=20= (nconc=20'(foo)=20x))=20=20=20=20=20=20=20=20=20=20=20;=20=20=20= @r{@code{foo}=20to=20the=20front=20of=20its=20arg.}=0A-@end=20group=0A-=0A= -@group=0A-(symbol-function=20'add-foo)=0A-=20=20=20=20=20@result{}=20= (lambda=20(x)=20(nconc=20'(foo)=20x))=0A-@end=20group=0A-=0A-@group=0A= -(setq=20xx=20(add-foo=20'(1=202)))=20=20=20=20;=20@r{It=20seems=20to=20= work.}=0A-=20=20=20=20=20@result{}=20(foo=201=202)=0A-@end=20group=0A= -@group=0A-(setq=20xy=20(add-foo=20'(3=204)))=20=20=20=20;=20@r{What=20= happened?}=0A-=20=20=20=20=20@result{}=20(foo=201=202=203=204)=0A-@end=20= group=0A-@group=0A-(eq=20xx=20xy)=0A-=20=20=20=20=20@result{}=20t=0A= -@end=20group=0A-=0A-@group=0A-(symbol-function=20'add-foo)=0A-=20=20=20=20= =20@result{}=20(lambda=20(x)=20(nconc=20'(foo=201=202=203=204)=20x))=0A= -@end=20group=0A-@end=20smallexample=0A+However,=20the=20other=20= arguments=20(all=20but=20the=20last)=20must=20be=20non-constant=20lists.=0A= =20@end=20defun=0A=20=0A=20@node=20Sets=20And=20Lists=0A@@=20-1260,7=20= +1226,7=20@@=20Sets=20And=20Lists=0A=20=0A=20@example=0A=20@group=0A= -(delq=20'a=20'(a=20b=20c))=20@equiv{}=20(cdr=20'(a=20b=20c))=0A+(delq=20= 'a=20(list=20'a=20'b=20'c))=20@equiv{}=20(cdr=20(list=20'a=20'b=20'c))=0A= =20@end=20group=0A=20@end=20example=0A=20=0A@@=20-1270,7=20+1236,7=20@@=20= Sets=20And=20Lists=0A=20=0A=20@example=0A=20@group=0A-(setq=20= sample-list=20'(a=20b=20c=20(4)))=0A+(setq=20sample-list=20(list=20'a=20= 'b=20'c=20'(4)))=0A=20=20=20=20=20=20@result{}=20(a=20b=20c=20(4))=0A=20= @end=20group=0A=20@group=0A@@=20-1407,7=20+1373,7=20@@=20Sets=20And=20= Lists=0A=20=0A=20@example=0A=20@group=0A-(setq=20l=20'((2)=20(1)=20(2)))=0A= +(setq=20l=20(list=20'(2)=20'(1)=20'(2)))=0A=20(delete=20'(2)=20l)=0A=20=20= =20=20=20=20@result{}=20((1))=0A=20l=0A@@=20-1416,7=20+1382,7=20@@=20= Sets=20And=20Lists=0A=20;;=20@r{write=20@code{(setq=20l=20(delete=20'(2)=20= l))}.}=0A=20@end=20group=0A=20@group=0A-(setq=20l=20'((2)=20(1)=20(2)))=0A= +(setq=20l=20(list=20'(2)=20'(1)=20'(2)))=0A=20(delete=20'(1)=20l)=0A=20=20= =20=20=20=20@result{}=20((2)=20(2))=0A=20l=0A@@=20-1759,7=20+1725,7=20@@=20= Association=20Lists=0A=20than=20looking=20at=20the=20saved=20value=20of=20= @var{alist}.=0A=20=0A=20@example=0A-(setq=20alist=20'((foo=201)=20(bar=20= 2)=20(foo=203)=20(lose=204)))=0A+(setq=20alist=20(list=20'(foo=201)=20= '(bar=202)=20'(foo=203)=20'(lose=204)))=0A=20=20=20=20=20=20@result{}=20= ((foo=201)=20(bar=202)=20(foo=203)=20(lose=204))=0A=20(assq-delete-all=20= 'foo=20alist)=0A=20=20=20=20=20=20@result{}=20((bar=202)=20(lose=204))=0A= @@=20-1926,7=20+1892,7=20@@=20Plist=20Access=0A=20in=20the=20place=20= where=20you=20got=20@var{plist}.=20=20For=20example,=0A=20=0A=20@example=0A= -(setq=20my-plist=20'(bar=20t=20foo=204))=0A+(setq=20my-plist=20(list=20= 'bar=20t=20'foo=204))=0A=20=20=20=20=20=20@result{}=20(bar=20t=20foo=20= 4)=0A=20(setq=20my-plist=20(plist-put=20my-plist=20'foo=2069))=0A=20=20=20= =20=20=20@result{}=20(bar=20t=20foo=2069)=0Adiff=20--git=20= a/doc/lispref/sequences.texi=20b/doc/lispref/sequences.texi=0Aindex=20= 1a3a04f680..d35b4d05e3=20100644=0A---=20a/doc/lispref/sequences.texi=0A= +++=20b/doc/lispref/sequences.texi=0A@@=20-183,7=20+183,7=20@@=20= Sequence=20Functions=0A=20=0A=20@example=0A=20@group=0A-(setq=20bar=20= '(1=202))=0A+(setq=20bar=20(list=201=202))=0A=20=20=20=20=20=20@result{}=20= (1=202)=0A=20@end=20group=0A=20@group=0A@@=20-278,7=20+278,7=20@@=20= Sequence=20Functions=0A=20=0A=20@example=0A=20@group=0A-(setq=20x=20'(a=20= b=20c))=0A+(setq=20x=20(list=20'a=20'b=20'c))=0A=20=20=20=20=20=20= @result{}=20(a=20b=20c)=0A=20@end=20group=0A=20@group=0A@@=20-374,11=20= +374,11=20@@=20Sequence=20Functions=0A=20=0A=20@example=0A=20@group=0A= -(setq=20nums=20'(1=203=202=206=205=204=200))=0A+(setq=20nums=20(list=20= 1=203=202=206=205=204=200))=0A=20=20=20=20=20=20@result{}=20(1=203=202=20= 6=205=204=200)=0A=20@end=20group=0A=20@group=0A-(sort=20nums=20'<)=0A= +(sort=20nums=20#'<)=0A=20=20=20=20=20=20@result{}=20(0=201=202=203=204=20= 5=206)=0A=20@end=20group=0A=20@group=0A@@=20-396,7=20+396,7=20@@=20= Sequence=20Functions=0A=20the=20variable=20that=20held=20the=20original=20= list:=0A=20=0A=20@example=0A-(setq=20nums=20(sort=20nums=20'<))=0A+(setq=20= nums=20(sort=20nums=20#'<))=0A=20@end=20example=0A=20=0A=20For=20the=20= better=20understanding=20of=20what=20stable=20sort=20is,=20consider=20= the=20following=0A@@=20-1228,7=20+1228,7=20@@=20Array=20Functions=0A=20=0A= =20@example=0A=20@group=0A-(setq=20w=20[foo=20bar=20baz])=0A+(setq=20w=20= (vector=20'foo=20'bar=20'baz))=0A=20=20=20=20=20=20@result{}=20[foo=20= bar=20baz]=0A=20(aset=20w=200=20'fu)=0A=20=20=20=20=20=20@result{}=20fu=0A= @@=20-1237,12=20+1237,12=20@@=20Array=20Functions=0A=20@end=20group=0A=20= =0A=20@group=0A-(setq=20x=20"asdfasfd")=0A-=20=20=20=20=20@result{}=20= "asdfasfd"=0A+(setq=20x=20(string=20?a=20?b=20?c=20?d=20?e))=0A+=20=20=20= =20=20@result{}=20"abcde"=0A=20(aset=20x=203=20?Z)=0A=20=20=20=20=20=20= @result{}=2090=0A=20x=0A-=20=20=20=20=20@result{}=20"asdZasfd"=0A+=20=20=20= =20=20@result{}=20"abcZe"=0A=20@end=20group=0A=20@end=20example=0A=20=0A= @@=20-1257,7=20+1257,7=20@@=20Array=20Functions=0A=20=0A=20@example=0A=20= @group=0A-(setq=20a=20[a=20b=20c=20d=20e=20f=20g])=0A+(setq=20a=20= (vector=20'a=20'b=20'c=20'd=20'e=20'f=20'g))=0A=20=20=20=20=20=20= @result{}=20[a=20b=20c=20d=20e=20f=20g]=0A=20(fillarray=20a=200)=0A=20=20= =20=20=20=20@result{}=20[0=200=200=200=200=200=200]=0A@@=20-1265,10=20= +1265,10=20@@=20Array=20Functions=0A=20=20=20=20=20=20@result{}=20[0=200=20= 0=200=200=200=200]=0A=20@end=20group=0A=20@group=0A-(setq=20s=20"When=20= in=20the=20course")=0A-=20=20=20=20=20@result{}=20"When=20in=20the=20= course"=0A+(setq=20s=20(string=20?S=20?e=20?c=20?r=20?e=20?t))=0A+=20=20=20= =20=20@result{}=20"Secret"=0A=20(fillarray=20s=20?-)=0A-=20=20=20=20=20= @result{}=20"------------------"=0A+=20=20=20=20=20@result{}=20"------"=0A= =20@end=20group=0A=20@end=20example=0A=20=0Adiff=20--git=20= a/doc/lispref/strings.texi=20b/doc/lispref/strings.texi=0Aindex=20= 14cabc5d79..3d375409a9=20100644=0A---=20a/doc/lispref/strings.texi=0A+++=20= b/doc/lispref/strings.texi=0A@@=20-591,7=20+591,7=20@@=20Text=20= Comparison=0A=20=0A=20@example=0A=20@group=0A-(sort=20'("11"=20"12"=20"1=20= 1"=20"1=202"=20"1.1"=20"1.2")=20'string-collate-lessp)=0A+(sort=20(list=20= "11"=20"12"=20"1=201"=20"1=202"=20"1.1"=20"1.2")=20= 'string-collate-lessp)=0A=20=20=20=20=20=20@result{}=20("11"=20"1=201"=20= "1.1"=20"12"=20"1=202"=20"1.2")=0A=20@end=20group=0A=20@end=20example=0A= @@=20-608,7=20+608,7=20@@=20Text=20Comparison=0A=20=0A=20@example=0A=20= @group=0A-(sort=20'("11"=20"12"=20"1=201"=20"1=202"=20"1.1"=20"1.2")=0A= +(sort=20(list=20"11"=20"12"=20"1=201"=20"1=202"=20"1.1"=20"1.2")=0A=20=20= =20=20=20=20=20(lambda=20(s1=20s2)=20(string-collate-lessp=20s1=20s2=20= "POSIX")))=0A=20=20=20=20=20=20@result{}=20("1=201"=20"1=202"=20"1.1"=20= "1.2"=20"11"=20"12")=0A=20@end=20group=0A--=20=0A2.21.1=20(Apple=20= Git-122.3)=0A=0A= --Apple-Mail=_5781C227-1A23-46FD-9E9D-ED3BE42938E6-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Apr 2020 17:28: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 To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158714446330622 (code B ref 40671); Fri, 17 Apr 2020 17:28:01 +0000 Received: (at 40671) by debbugs.gnu.org; 17 Apr 2020 17:27:43 +0000 Received: from localhost ([127.0.0.1]:41622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPUmF-0007xo-I6 for submit@debbugs.gnu.org; Fri, 17 Apr 2020 13:27:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPUmB-0007xX-L4 for 40671@debbugs.gnu.org; Fri, 17 Apr 2020 13:27:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jPUm6-00056U-H8; Fri, 17 Apr 2020 13:27:34 -0400 Received: from [176.228.60.248] (port=3008 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jPUm4-0003WV-5Z; Fri, 17 Apr 2020 13:27:32 -0400 Date: Fri, 17 Apr 2020 20:27:21 +0300 Message-Id: <83pnc6aupy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Fri, 17 Apr 2020 18:37:23 +0200) References: <0B653323-49E1-4AC7-A85B-18346D220585@acm.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -1.5 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.5 (--) > From: Mattias Engdegård > Date: Fri, 17 Apr 2020 18:37:23 +0200 > Cc: Kevin Vigouroux > > > Can we modify literal objects? > > No, and the manual should do a much better job at explaining this. At the very least it should not promulgate bad ideas by including mutation of literals in example code. Patch attached, suggested for emacs-27. I don't see any explanation of the issue in the patch, did I miss something? What I see summarily replaces literal lists and cons cells with a calls to functions, and I'm not sure this is a step in the right direction. It definitely complicates the examples, which is not necessarily TRT, methodologically, for such introductory sections. From unknown Tue Jun 17 22:07:41 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Kevin Vigouroux Subject: bug#40671: closed (Re: [DOC] modify literal objects) Message-ID: References: <87v9lzmdrw.fsf@laposte.net> X-Gnu-PR-Message: they-closed 40671 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 40671@debbugs.gnu.org Date: Sat, 18 Apr 2020 20:11:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1587240662-11465-1" This is a multi-part message in MIME format... ------------=_1587240662-11465-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #40671: [DOC] modify literal objects which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 40671@debbugs.gnu.org. --=20 40671: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D40671 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1587240662-11465-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 40671-done) by debbugs.gnu.org; 18 Apr 2020 20:10:45 +0000 Received: from localhost ([127.0.0.1]:43627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPtnY-0002yL-5h for submit@debbugs.gnu.org; Sat, 18 Apr 2020 16:10:45 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPtnW-0002y9-3M for 40671-done@debbugs.gnu.org; Sat, 18 Apr 2020 16:10:43 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9A09F1600C7; Sat, 18 Apr 2020 13:10:36 -0700 (PDT) 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 ZsGAYoTc94Qn; Sat, 18 Apr 2020 13:10:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 66CAE1600D1; Sat, 18 Apr 2020 13:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 39L9RBip98km; Sat, 18 Apr 2020 13:10:34 -0700 (PDT) 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 0E4901600C7; Sat, 18 Apr 2020 13:10:34 -0700 (PDT) To: =?UTF-8?Q?Mattias_Engdeg=c3=a5rd?= From: Paul Eggert Subject: Re: [DOC] modify literal objects Organization: UCLA Computer Science Department Message-ID: Date: Sat, 18 Apr 2020 13:10:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------A896A9B4828B158D84249FAF" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40671-done Cc: Kevin Vigouroux , Eli Zaretskii , 40671-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------A896A9B4828B158D84249FAF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Mattias, thanks for going through the Emacs manual and looking for mistakes in this area. I know it was a pain to do that, since I did something similar in parallel and it was painful for me. I used your patch to crosscheck with my draft (finding omissions on both sides) and installed the resulting patch (attached) into the emacs-27 branch. This patch should address the points that Eli raised. That is, it adds explanations of the issue (both in the intro and the reference manual, since the issue also infects the intro), and it attempts to change examples only when the changes are needed to avoid undefined behavior in Emacs Lisp. I also kept the changes from '< to #'< that were in your patch since that's good style. --------------A896A9B4828B158D84249FAF Content-Type: text/x-patch; charset=UTF-8; name="0001-Document-constant-vs-mutable-objects-better.patch" Content-Disposition: attachment; filename="0001-Document-constant-vs-mutable-objects-better.patch" Content-Transfer-Encoding: quoted-printable >From eebfb72c906755c0a80d92c11deee7ac9faf5f4b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 18 Apr 2020 12:59:17 -0700 Subject: [PATCH] Document constant vs mutable objects better MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit This patch builds on a suggested patch by Mattias Engdeg=C3=A5rd and on further comments by Eli Zaretskii. Original bug report by Kevin Vigouroux (Bug#40671). * doc/lispintro/emacs-lisp-intro.texi (set & setq, Review) (setcar, Lists diagrammed, Mail Aliases, Indent Tabs Mode): setq is a special form, not a function or command. * doc/lispintro/emacs-lisp-intro.texi (setcar): * doc/lispref/lists.texi (Modifying Lists, Rearrangement): * doc/lispref/sequences.texi (Sequence Functions) (Array Functions, Vectors): * doc/lispref/strings.texi (String Basics, Modifying Strings): Mention mutable vs constant objects. * doc/lispintro/emacs-lisp-intro.texi (setcar, setcdr) (kill-new function, cons & search-fwd Review): * doc/lispref/edebug.texi (Printing in Edebug): * doc/lispref/keymaps.texi (Changing Key Bindings): * doc/lispref/lists.texi (Setcar, Setcdr, Rearrangement) (Sets And Lists, Association Lists, Plist Access): * doc/lispref/sequences.texi (Sequence Functions) (Array Functions): * doc/lispref/strings.texi (Text Comparison): Fix examples so that they do not try to change constants. --- doc/lispintro/emacs-lisp-intro.texi | 32 +++++++++------ doc/lispref/edebug.texi | 2 +- doc/lispref/keymaps.texi | 8 ++-- doc/lispref/lists.texi | 60 +++++++++++++++++------------ doc/lispref/sequences.texi | 31 +++++++++------ doc/lispref/strings.texi | 17 +++++--- 6 files changed, 91 insertions(+), 59 deletions(-) diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-li= sp-intro.texi index bd688070a3..630676d978 100644 --- a/doc/lispintro/emacs-lisp-intro.texi +++ b/doc/lispintro/emacs-lisp-intro.texi @@ -2329,7 +2329,7 @@ area. =20 @cindex @samp{bind} defined There are several ways by which a variable can be given a value. One of -the ways is to use either the function @code{set} or the function +the ways is to use either the function @code{set} or the special form @code{setq}. Another way is to use @code{let} (@pxref{let}). (The jargon for this process is to @dfn{bind} a variable to a value.) =20 @@ -4517,7 +4517,7 @@ number; it will be printed as the character with th= at @sc{ascii} code. =20 @item setq @itemx set -The @code{setq} function sets the value of its first argument to the +The @code{setq} special form sets the value of its first argument to the value of the second argument. The first argument is automatically quoted by @code{setq}. It does the same for succeeding pairs of arguments. Another function, @code{set}, takes only two arguments and @@ -7317,11 +7317,21 @@ which leave the original list as it was. One way= to find out how this works is to experiment. We will start with the @code{setcar} function. =20 @need 1200 +@cindex constant lists +@cindex mutable lists First, we can make a list and then set the value of a variable to the -list, using the @code{setq} function. Here is a list of animals: +list, using the @code{setq} special form. Because we intend to use +@code{setcar} to change the list, this @code{setq} should not use the +quoted form @code{'(antelope giraffe lion tiger)}, as that would yield +a list that is part of the program and bad things could happen if we +tried to change part of the program while running it. Generally +speaking an Emacs Lisp program's components should be constant (or +unchanged) while the program is running. So we instead construct an +animal list that is @dfn{mutable} (or changeable) by using the +@code{list} function, as follows: =20 @smallexample -(setq animals '(antelope giraffe lion tiger)) +(setq animals (list 'antelope 'giraffe 'lion 'tiger)) @end smallexample =20 @noindent @@ -7398,7 +7408,7 @@ To see how this works, set the value of the variabl= e to a list of domesticated animals by evaluating the following expression: =20 @smallexample -(setq domesticated-animals '(horse cow sheep goat)) +(setq domesticated-animals (list 'horse 'cow 'sheep 'goat)) @end smallexample =20 @need 1200 @@ -8846,7 +8856,7 @@ and then find the value of @code{trees}: =20 @smallexample @group -(setq trees '(maple oak pine birch)) +(setq trees (list 'maple 'oak 'pine 'birch)) @result{} (maple oak pine birch) @end group =20 @@ -9366,7 +9376,7 @@ For example: =20 @smallexample @group -(setq triple '(1 2 3)) +(setq triple (list 1 2 3)) =20 (setcar triple '37) =20 @@ -9547,7 +9557,7 @@ part of which is the address of the next pair. The= very last box points to the symbol @code{nil}, which marks the end of the list. =20 @need 1200 -When a variable is set to a list with a function such as @code{setq}, +When a variable is set to a list via @code{setq}, it stores the address of the first box in the variable. Thus, evaluation of the expression =20 @@ -17092,7 +17102,7 @@ reminders. =20 @cindex Mail aliases @noindent -This @code{setq} command sets the value of the variable +This @code{setq} sets the value of the variable @code{mail-aliases} to @code{t}. Since @code{t} means true, the line says, in effect, ``Yes, use mail aliases.'' =20 @@ -17130,8 +17140,8 @@ The following turns off Indent Tabs mode: @end smallexample =20 Note that this line uses @code{setq-default} rather than the -@code{setq} command that we have seen before. The @code{setq-default} -command sets values only in buffers that do not have their own local +@code{setq} that we have seen before. The @code{setq-default} +sets values only in buffers that do not have their own local values for the variable. =20 @ifinfo diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi index 8be8307c75..ec76e83db1 100644 --- a/doc/lispref/edebug.texi +++ b/doc/lispref/edebug.texi @@ -858,7 +858,7 @@ to a non-@code{nil} value. Here is an example of code that creates a circular structure: =20 @example -(setq a '(x y)) +(setq a (list 'x 'y)) (setcar a a) @end example =20 diff --git a/doc/lispref/keymaps.texi b/doc/lispref/keymaps.texi index c6a02d721f..4db9969767 100644 --- a/doc/lispref/keymaps.texi +++ b/doc/lispref/keymaps.texi @@ -1441,10 +1441,10 @@ Here is an example showing a keymap before and af= ter substitution: =20 @smallexample @group -(setq map '(keymap - (?1 . olddef-1) - (?2 . olddef-2) - (?3 . olddef-1))) +(setq map (list 'keymap + (cons ?1 olddef-1) + (cons ?2 olddef-2) + (cons ?3 olddef-1))) @result{} (keymap (49 . olddef-1) (50 . olddef-2) (51 . olddef-1)) @end group =20 diff --git a/doc/lispref/lists.texi b/doc/lispref/lists.texi index 27fa5385e3..c2771b0165 100644 --- a/doc/lispref/lists.texi +++ b/doc/lispref/lists.texi @@ -866,10 +866,16 @@ foo ;; @r{@code{foo} was chan= ged.} @node Modifying Lists @section Modifying Existing List Structure @cindex destructive list operations +@cindex constant lists +@cindex mutable lists =20 You can modify the @sc{car} and @sc{cdr} contents of a cons cell with = the primitives @code{setcar} and @code{setcdr}. These are destructive operations because they change existing list structure. +Destructive operations should be applied only to @dfn{mutable} lists, +that is, lists constructed via @code{cons}, @code{list} or similar +operations. Lists created by quoting are constants and should not be +changed by destructive operations. =20 @cindex CL note---@code{rplaca} vs @code{setcar} @quotation @@ -906,7 +912,7 @@ value @var{object}. For example: =20 @example @group -(setq x '(1 2)) +(setq x (list 1 2)) @result{} (1 2) @end group @group @@ -927,7 +933,7 @@ these lists. Here is an example: @example @group ;; @r{Create two lists that are partly shared.} -(setq x1 '(a b c)) +(setq x1 (list 'a 'b 'c)) @result{} (a b c) (setq x2 (cons 'z (cdr x1))) @result{} (z b c) @@ -1017,7 +1023,7 @@ reached via the @sc{cdr}. =20 @example @group -(setq x '(1 2 3)) +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group @@ -1037,7 +1043,7 @@ the @sc{cdr} of the first cons cell: =20 @example @group -(setq x1 '(a b c)) +(setq x1 (list 'a 'b 'c)) @result{} (a b c) (setcdr x1 (cdr (cdr x1))) @result{} (c) @@ -1069,7 +1075,7 @@ of this list. =20 @example @group -(setq x1 '(a b c)) +(setq x1 (list 'a 'b 'c)) @result{} (a b c) (setcdr x1 (cons 'd (cdr x1))) @result{} (d b c) @@ -1130,7 +1136,7 @@ Unlike @code{append} (@pxref{Building Lists}), the = @var{lists} are =20 @example @group -(setq x '(1 2 3)) +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group @@ -1150,7 +1156,7 @@ list: =20 @example @group -(setq x '(1 2 3)) +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group @@ -1163,11 +1169,13 @@ x @end group @end example =20 -However, the other arguments (all but the last) must be lists. +However, the other arguments (all but the last) must be mutable lists. =20 A common pitfall is to use a quoted constant list as a non-last -argument to @code{nconc}. If you do this, your program will change -each time you run it! Here is what happens: +argument to @code{nconc}. If you do this, the resulting behavior +is undefined. It is possible that your program will change +each time you run it! Here is what might happen (though this +is not guaranteed to happen): =20 @smallexample @group @@ -1260,7 +1268,9 @@ after those elements. For example: =20 @example @group -(delq 'a '(a b c)) @equiv{} (cdr '(a b c)) +(equal + (delq 'a (list 'a 'b 'c)) + (cdr (list 'a 'b 'c))) @end group @end example =20 @@ -1270,7 +1280,7 @@ removing it involves changing the @sc{cdr}s (@pxref= {Setcdr}). =20 @example @group -(setq sample-list '(a b c (4))) +(setq sample-list (list 'a 'b 'c '(4))) @result{} (a b c (4)) @end group @group @@ -1303,12 +1313,12 @@ into the variable that held the original list: (setq flowers (delq 'rose flowers)) @end example =20 -In the following example, the @code{(4)} that @code{delq} attempts to ma= tch -and the @code{(4)} in the @code{sample-list} are not @code{eq}: +In the following example, the @code{(list 4)} that @code{delq} attempts = to match +and the @code{(4)} in the @code{sample-list} are @code{equal} but not @c= ode{eq}: =20 @example @group -(delq '(4) sample-list) +(delq (list 4) sample-list) @result{} (a c (4)) @end group @end example @@ -1324,7 +1334,7 @@ of @code{list}. =20 @example @group -(setq sample-list '(a b c a b c)) +(setq sample-list (list 'a 'b 'c 'a 'b 'c)) @result{} (a b c a b c) @end group @group @@ -1353,7 +1363,7 @@ Compare this with @code{memq}: @result{} (1.2 1.3) @end group @group -(memq 1.2 '(1.1 1.2 1.3)) ; @r{@code{1.2} and @code{1.2} are not @code{= eq}.} +(memq (list 2) '((1) (2))) ; @r{@code{(list 2)} and @code{(2)} are not = @code{eq}.} @result{} nil @end group @end example @@ -1373,11 +1383,11 @@ Compare this with @code{memq}: =20 @example @group -(member '(2) '((1) (2))) ; @r{@code{(2)} and @code{(2)} are @code{equal= }.} +(member (list 2) '((1) (2))) ; @r{@code{(list 2)} and @code{(2)} are @c= ode{equal}.} @result{} ((2)) @end group @group -(memq '(2) '((1) (2))) ; @r{@code{(2)} and @code{(2)} are not @code{e= q}.} +(memq (list 2) '((1) (2))) ; @r{@code{(list 2)} and @code{(2)} are no= t @code{eq}.} @result{} nil @end group @group @@ -1407,7 +1417,7 @@ For example: =20 @example @group -(setq l '((2) (1) (2))) +(setq l (list '(2) '(1) '(2))) (delete '(2) l) @result{} ((1)) l @@ -1416,7 +1426,7 @@ l ;; @r{write @code{(setq l (delete '(2) l))}.} @end group @group -(setq l '((2) (1) (2))) +(setq l (list '(2) '(1) '(2))) (delete '(1) l) @result{} ((2) (2)) l @@ -1618,9 +1628,9 @@ keys may not be symbols: '(("simple leaves" . oak) ("compound leaves" . horsechestnut))) =20 -(assq "simple leaves" leaves) +(assq (copy-sequence "simple leaves") leaves) @result{} nil -(assoc "simple leaves" leaves) +(assoc (copy-sequence "simple leaves") leaves) @result{} ("simple leaves" . oak) @end smallexample @end defun @@ -1759,7 +1769,7 @@ correct results, use the return value of @code{assq= -delete-all} rather than looking at the saved value of @var{alist}. =20 @example -(setq alist '((foo 1) (bar 2) (foo 3) (lose 4))) +(setq alist (list '(foo 1) '(bar 2) '(foo 3) '(lose 4))) @result{} ((foo 1) (bar 2) (foo 3) (lose 4)) (assq-delete-all 'foo alist) @result{} ((bar 2) (lose 4)) @@ -1926,7 +1936,7 @@ function returns the modified property list, so you= can store that back in the place where you got @var{plist}. For example, =20 @example -(setq my-plist '(bar t foo 4)) +(setq my-plist (list 'bar t 'foo 4)) @result{} (bar t foo 4) (setq my-plist (plist-put my-plist 'foo 69)) @result{} (bar t foo 69) diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi index 1a3a04f680..f6faf9448c 100644 --- a/doc/lispref/sequences.texi +++ b/doc/lispref/sequences.texi @@ -183,7 +183,7 @@ for other ways to copy sequences. =20 @example @group -(setq bar '(1 2)) +(setq bar (list 1 2)) @result{} (1 2) @end group @group @@ -278,7 +278,7 @@ Unlike @code{reverse} the original @var{sequence} may= be modified. =20 @example @group -(setq x '(a b c)) +(setq x (list 'a 'b 'c)) @result{} (a b c) @end group @group @@ -320,7 +320,7 @@ presented graphically: For the vector, it is even simpler because you don't need setq: =20 @example -(setq x [1 2 3 4]) +(setq x (copy-sequence [1 2 3 4])) @result{} [1 2 3 4] (nreverse x) @result{} [4 3 2 1] @@ -330,7 +330,7 @@ x =20 Note that unlike @code{reverse}, this function doesn't work with strings= . Although you can alter string data by using @code{aset}, it is strongly -encouraged to treat strings as immutable. +encouraged to treat strings as immutable even when they are mutable. =20 @end defun =20 @@ -374,11 +374,11 @@ appears in a different position in the list due to = the change of =20 @example @group -(setq nums '(1 3 2 6 5 4 0)) +(setq nums (list 1 3 2 6 5 4 0)) @result{} (1 3 2 6 5 4 0) @end group @group -(sort nums '<) +(sort nums #'<) @result{} (0 1 2 3 4 5 6) @end group @group @@ -396,7 +396,7 @@ of @code{sort} and use that. Most often we store the= result back into the variable that held the original list: =20 @example -(setq nums (sort nums '<)) +(setq nums (sort nums #'<)) @end example =20 For the better understanding of what stable sort is, consider the follow= ing @@ -1228,7 +1228,7 @@ This function sets the @var{index}th element of @va= r{array} to be =20 @example @group -(setq w [foo bar baz]) +(setq w (vector 'foo 'bar 'baz)) @result{} [foo bar baz] (aset w 0 'fu) @result{} fu @@ -1237,7 +1237,8 @@ w @end group =20 @group -(setq x "asdfasfd") +;; @r{@code{copy-sequence} creates a mutable string.} +(setq x (copy-sequence "asdfasfd")) @result{} "asdfasfd" (aset x 3 ?Z) @result{} 90 @@ -1246,6 +1247,10 @@ x @end group @end example =20 +The @var{array} should be mutable; that is, it should not be a constant, +such as the constants created via quoting or via self-evaluating forms. +@xref{Self-Evaluating Forms}. + If @var{array} is a string and @var{object} is not a character, a @code{wrong-type-argument} error results. The function converts a unibyte string to multibyte if necessary to insert a character. @@ -1257,7 +1262,7 @@ each element of @var{array} is @var{object}. It re= turns @var{array}. =20 @example @group -(setq a [a b c d e f g]) +(setq a (copy-sequence [a b c d e f g])) @result{} [a b c d e f g] (fillarray a 0) @result{} [0 0 0 0 0 0 0] @@ -1265,7 +1270,7 @@ a @result{} [0 0 0 0 0 0 0] @end group @group -(setq s "When in the course") +(setq s (copy-sequence "When in the course")) @result{} "When in the course" (fillarray s ?-) @result{} "------------------" @@ -1301,7 +1306,9 @@ same way in Lisp input. =20 A vector, like a string or a number, is considered a constant for evaluation: the result of evaluating it is the same vector. This does -not evaluate or even examine the elements of the vector. +not evaluate or even examine the elements of the vector. Vectors +written with square brackets are constants and should not be modified +via @code{aset} or other destructive operations. @xref{Self-Evaluating Forms}. =20 Here are examples illustrating these principles: diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi index 14cabc5d79..3acbf538dc 100644 --- a/doc/lispref/strings.texi +++ b/doc/lispref/strings.texi @@ -51,10 +51,8 @@ by a distinguished character code. operate on them with the general array and sequence functions documented in @ref{Sequences Arrays Vectors}. For example, you can access or change individual characters in a string using the functions @code{aref} -and @code{aset} (@pxref{Array Functions}). However, note that -@code{length} should @emph{not} be used for computing the width of a -string on display; use @code{string-width} (@pxref{Size of Displayed -Text}) instead. +and @code{aset} (@pxref{Array Functions}). However, you should not +try to change the contents of constant strings (@pxref{Modifying Strings= }). =20 There are two text representations for non-@acronym{ASCII} characters in Emacs strings (and in buffers): unibyte and multibyte. @@ -89,6 +87,9 @@ copy them into buffers. @xref{Character Type}, and @re= f{String Type}, for information about the syntax of characters and strings. @xref{Non-ASCII Characters}, for functions to convert between text representations and to encode and decode character codes. +Also, note that @code{length} should @emph{not} be used for computing +the width of a string on display; use @code{string-width} (@pxref{Size +of Displayed Text}) instead. =20 @node Predicates for Strings @section Predicates for Strings @@ -380,6 +381,10 @@ usual value is @w{@code{"[ \f\t\n\r\v]+"}}. @cindex modifying strings @cindex string modification =20 + You can alter the contents of a mutable string via operations +described in this section. However, you should not try to use these +operations to alter the contents of a constant string. + The most basic way to alter the contents of an existing string is with @code{aset} (@pxref{Array Functions}). @code{(aset @var{string} @var{idx} @var{char})} stores @var{char} into @var{string} at index @@ -591,7 +596,7 @@ for sorting (@pxref{Sequence Functions}): =20 @example @group -(sort '("11" "12" "1 1" "1 2" "1.1" "1.2") 'string-collate-lessp) +(sort (list "11" "12" "1 1" "1 2" "1.1" "1.2") 'string-collate-lessp) @result{} ("11" "1 1" "1.1" "12" "1 2" "1.2") @end group @end example @@ -608,7 +613,7 @@ systems. The @var{locale} value of @code{"POSIX"} or= @code{"C"} lets =20 @example @group -(sort '("11" "12" "1 1" "1 2" "1.1" "1.2") +(sort (list "11" "12" "1 1" "1 2" "1.1" "1.2") (lambda (s1 s2) (string-collate-lessp s1 s2 "POSIX"))) @result{} ("1 1" "1 2" "1.1" "1.2" "11" "12") @end group --=20 2.17.1 --------------A896A9B4828B158D84249FAF-- ------------=_1587240662-11465-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 16 Apr 2020 20:39:37 +0000 Received: from localhost ([127.0.0.1]:39448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPBIO-0006Qo-7a for submit@debbugs.gnu.org; Thu, 16 Apr 2020 16:39:37 -0400 Received: from lists.gnu.org ([209.51.188.17]:49510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPABO-0004ek-Jr for submit@debbugs.gnu.org; Thu, 16 Apr 2020 15:28:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51971) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPABM-0002Lt-Tn for bug-gnu-emacs@gnu.org; Thu, 16 Apr 2020 15:28:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_50,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,SPOOFED_FREEMAIL,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jPABJ-0001rO-DB for bug-gnu-emacs@gnu.org; Thu, 16 Apr 2020 15:28:14 -0400 Received: from smtpoutz22.laposte.net ([194.117.213.97]:37395 helo=smtp.laposte.net) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jPABI-0001mD-UF for bug-gnu-emacs@gnu.org; Thu, 16 Apr 2020 15:28:13 -0400 Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout010 (Postfix) with ESMTP id 89DA84B241E for ; Thu, 16 Apr 2020 21:28:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=laposte.net; s=mail0; t=1587065284; bh=q8KfU+TIs9FYwEGP4OnsPMQdzi+dztG0Ta4pxZLbg78=; h=From:To:Subject:Date; b=YG+Jjg/15ql/9awHgu5xwqFrKWiNHQQt5X3m9L4gJ+CJ5SGNOJlkyPICpkvlOm7sT JXu5psFJtMUFkwMyERt5gK/GvlVw7ogsaXmE6YPO+e45286D5DFfwOz4PNjdBdjPzm t4J9jwHLSElAcfxiWTpDF9H9Nn8+AgGtGR9KinXiTd8H5rKwsbeuu9Y+G44UrDzV6C dhaRstWjgDF3Wb0MW9RQ3/hXTBn/Au9NlJ5YQE2sjhsFYNTroggtPqoqQdewFGFVUz aC99I22iOA8MkQGnTYR85uzPg2XCNnJ5072uFphaJbCBNTj/G5dsIzxq2wEeXzvgUS 2AOXF93yIlVlQ== Received: from outgoing-mail.laposte.net (unknown [10.94.128.98]) by lpn-prd-vrout010 (Postfix) with ESMTP id 842114B241C for ; Thu, 16 Apr 2020 21:28:04 +0200 (CEST) Received: from outgoing-mail.laposte.net (localhost.localdomain [127.0.0.1]) by mlpnf0119.laposte.net (SMTP Server) with ESMTP id 4938QD3YZpz1qqj0 for ; Thu, 16 Apr 2020 21:28:04 +0200 (CEST) X-ppbforward: {"queueID":"4938QD3YZpz1qqj0","server":"mlpnf0119"} X-mail-filterd: 0.4.0.2 X-mail-filterd: 0.4.0.2 X-ppbforward: {"queueID":"4938QD27Vvz1qqhy","server":"mlpnf0119"} X-lpn-spamrating: 40 X-lpn-spamlevel: not-spam X-lpn-spamcause: OK, (0)(0000)gggruggvucftvghtrhhoucdtuddrgeduhedrfeehgddufeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecunfetrffquffvgfdpqfgfvfdpggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkgggtsehttdertddttddtnecuhfhrohhmpefmvghvihhnucggihhgohhurhhouhiguceokhgvrdhvihhgohhurhhouhigsehlrghpohhsthgvrdhnvghtqeenucffohhmrghinhepshhtrggtkhgvgigthhgrnhhgvgdrtghomhenucfkphepledtrdefvddrudduiedrfedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepsghluhgvmhgrnhdpihhnvghtpeeltddrfedvrdduudeirdeftddpmhgrihhlfhhrohhmpehkvgdrvhhighhouhhrohhugieslhgrphhoshhtvgdrnhgvthdprhgtphhtthhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnhhurdhorhhg X-lpn-mailing: LEGIT Received: from blueman (arennes-256-1-117-30.w90-32.abo.wanadoo.fr [90.32.116.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mlpnf0119.laposte.net (SMTP Server) with ESMTPSA id 4938QD27Vvz1qqhy for ; Thu, 16 Apr 2020 21:28:04 +0200 (CEST) From: Kevin Vigouroux To: bug-gnu-emacs@gnu.org Subject: [DOC] modify literal objects Date: Thu, 16 Apr 2020 21:28:03 +0200 Message-ID: <87v9lzmdrw.fsf@laposte.net> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 194.117.213.97 X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello! The Emacs Lisp manual often gives the impression that the user can modify literal lists (e.g. 5.6.1 Altering List Elements with `setcar`). LISP> (setq x '(1 2)) (1 2) LISP> (setcar x 4) LISP> x (4 2) Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: stackexchange.com] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [209.51.188.17 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ke.vigouroux[at]laposte.net) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/Why?s=mfrom; id=ke.vigouroux%40laposte.net; ip=209.51.188.17; r=debbugs.gnu.org] 2.0 SPOOFED_FREEMAIL No description available. X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 16 Apr 2020 16:39:35 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hello! The Emacs Lisp manual often gives the impression that the user can modify literal lists (e.g. 5.6.1 Altering List Elements with `setcar`). LISP> (setq x '(1 2)) (1 2) LISP> (setcar x 4) LISP> x (4 2) However, it is also mentioned that one should not modify the literal objects because of the byte compilation (c.f. 2.7 Equality Predicate). Can we modify literal objects? See Also: https://emacs.stackexchange.com/questions/45820/when-to-use-quote-for-lists-modifying-quoted-lists-in-elisp https://emacs.stackexchange.com/questions/57806/which-lisp-objects-are-byte-compiled Best regards, Kevin Vigouroux. ------------=_1587240662-11465-1-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Apr 2020 21:55: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 To: Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671-done@debbugs.gnu.org Received: via spool by 40671-done@debbugs.gnu.org id=D40671.158724690021934 (code D ref 40671); Sat, 18 Apr 2020 21:55:02 +0000 Received: (at 40671-done) by debbugs.gnu.org; 18 Apr 2020 21:55:00 +0000 Received: from localhost ([127.0.0.1]:43713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPvQR-0005hi-6q for submit@debbugs.gnu.org; Sat, 18 Apr 2020 17:55:00 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:48968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPvQM-0005hN-51 for 40671-done@debbugs.gnu.org; Sat, 18 Apr 2020 17:54:58 -0400 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 03ILmUu5151638; Sat, 18 Apr 2020 21:54:37 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=dOrl2LR6v6XWsFJaInodI2OBzdOZlOehhfiyP4uXHd4=; b=MoQOViHZb2XYW0WFNAucfqGgB5aDOEF7gw4qRz7d4mvhuwawXa1WFAc6tZ+avx9VcUck GtRcZMWxiHJNFtGm4QJSGwhYzoE2yIeyaVTyrT06xcv5VXqb2V6zGTl5KQnV2KotkpuZ 67cvhrWf53aF0uBTfiOfA996FSvy+CEqRiPZL9e/Z0OX+bnAa/K2LoVc25/GWVUjwlrx c2DDUvQmxv+qp8eOWRSmNquh0pH2RjpzBC9WVLzUZyfNu16nDCHZMQe89vsnZlar11JW 3tYtuz2UzUHvGLLHaXSm5ewC2ESVbN5wINyz6cmm+MwSE17cLbBQT6dSfr6pCciEeRNu Vw== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 30fsgkhyub-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 18 Apr 2020 21:54:37 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03ILmHwP067448; Sat, 18 Apr 2020 21:54:37 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 30fvfd8g07-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 18 Apr 2020 21:54:37 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03ILsXJt006447; Sat, 18 Apr 2020 21:54:34 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 18 Apr 2020 14:54:32 -0700 (PDT) From: Drew Adams References: <87v9lzmdrw.fsf@laposte.net> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4966.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9595 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 bulkscore=0 mlxscore=0 malwarescore=0 suspectscore=0 spamscore=0 mlxlogscore=911 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004180181 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9595 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=961 malwarescore=0 clxscore=1011 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-2004180181 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) OK, here's a nitpick, FWIW. ___ You say things such as this: "should be applied only to @dfn{mutable} lists, that is, lists constructed via @code{cons}, @code{list} or similar operations." That's not a usual meaning of "mutable". Your "that is" makes clear what you mean, sort of, I suppose. That part is clear enough, but it's not a good "definition" of "mutable". It's about code that always creates new list structure, versus code that might create new list structure only sometimes (e.g. the first time it's encountered). A quoted list, which you call "constant", is in fact mutable in some contexts. An immutable list would be one you couldn't ever change - it would truly be a constant. That can be true for the result of byte-compiling a quoted list. But it's not true in general for interpreted code. E.g., this example in (elisp) `Setcdr': (setq x '(1 2 3)) =E2=87=92 (1 2 3) (setcdr x '(4)) =E2=87=92 (4) x =E2=87=92 (1 4) What you're really trying to convey presumably is not that one CANNOT ever modify such a list, but that one SHOULD NOT modify such a list (e.g. because of what can happen to it with the byte compiler). That's something different, and I don't think the message comes across well. Similarly: "However, the other arguments (all but the last) must be mutable lists." "MUST" means you CANNOT do otherwise. Trying to do so might result in an error being raised, for example. And that's not always the case. Hence the gotcha, hence the need for a guideline: Don't do it; just say no. That text with "must" is immediately followed by: "A common pitfall is to use a quoted constant list..." And _that's_ the point. But together with your text saying you CANNOT modify it anyway, things get confusing. Modifying a quoted list is problematic, a gotcha, a pitfall, something to avoid. You SHOULD NOT do it precisely because you CAN do it sometimes. If you couldn't, e.g., if you were prevented from doing it by always raising an error, then there would be no gotcha, no reason to tell you not to do it. Anyway, you get the idea. BTW, "a quoted constant list" is a bit poorly worded, as well. (Yes, that text was already there.) The problem is using a quoted list sexp, which can have the effect of producing a constant list. It's not about quoting a list that is somehow already a constant. Quoting can _produce_ a constant. --- FWIW, Common Lisp doesn't talk about mutable or immutable lists (or other objects):=20 "The consequences are undefined if literal objects (including quoted objects) are destructively modified." Undefined. They CAN sometimes be destructively modified. And a proposal says to: "clarify that it is an error to destructively modify objects which are self-evaluating forms or which appear inside of a QUOTE special form." And it talks of: "modifying quoted data structures" Such wording makes clear which things we're talking about. Cltl says only: "implicit sharing of compiled data structures may result in unpredictable behavior if destructive operations are performed. However, CLtL does not explicitly allow or disallow destructive operations on constants." Unpredictable behavior. It doesn't say it's always impossible to modify such things. It says, in effect, don't try. That's what we should say for Emacs Lisp, since we do NOT "disallow modification of constants consistently in all situations." For Emacs Lisp this is a gotcha, so we need a SHOULD. If it were enforced as a MUST then we wouldn't need such a caveat. This was proposed for CL: "Disallowing modification of constants consistently in all situations, rather than just in compiled code, is proposed because in some compiled-only situations it may be difficult to distinguish between "compiled" and "interpreted" code." Whether "disallow" means raise an error in all such cases (which was proposed for Cltl) or just warn users not to do it and say the behavior is "undefined" (what Cltl did, and what Emacs should do), is a separate question. The point about trying to modify a quoted list, for Emacs Lisp, is this: Don't do it. Don't assume that you get new list structure each time it looks like a quoted list will be evaluated anew. It might be evaluated only once, and the result used as a constant thereafter. http://clhs.lisp.se/Issues/iss083_w.htm From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 02:27: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org Reply-To: rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158726317216236 (code B ref 40671); Sun, 19 Apr 2020 02:27:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 02:26:12 +0000 Received: from localhost ([127.0.0.1]:43873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPzeu-0004Do-6X for submit@debbugs.gnu.org; Sat, 18 Apr 2020 22:26:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPzes-0004Da-Hh for 40671@debbugs.gnu.org; Sat, 18 Apr 2020 22:26:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44601) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPzel-0000eA-Ur; Sat, 18 Apr 2020 22:26:03 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jPzek-00057B-EP; Sat, 18 Apr 2020 22:26:02 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: (message from Paul Eggert on Sat, 18 Apr 2020 13:10:30 -0700) References: <87v9lzmdrw.fsf@laposte.net> Message-Id: Date: Sat, 18 Apr 2020 22:26:02 -0400 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Thanks to both of you for working on updating the Emacs Lisp Intro. Its author, Bob Chassell, became incapacitated many years before his death, so it has not had the needed attention for quite some time. I would be surprised if it didn't have other problems due to the changes that we have made in Emacs Lisp since 20 years ago. Would anyone like to pick some chapter and read it looking for anything that needs updating? Not only things that are now incorrect, but anything that is not clear to beginners. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 02:40: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 To: Drew Adams Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Paul Eggert , 40671-done@debbugs.gnu.org, Kevin Vigouroux Received: via spool by 40671-done@debbugs.gnu.org id=D40671.158726398117550 (code D ref 40671); Sun, 19 Apr 2020 02:40:02 +0000 Received: (at 40671-done) by debbugs.gnu.org; 19 Apr 2020 02:39:41 +0000 Received: from localhost ([127.0.0.1]:43897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPzrx-0004Yz-7G for submit@debbugs.gnu.org; Sat, 18 Apr 2020 22:39:41 -0400 Received: from mail-oi1-f178.google.com ([209.85.167.178]:39797) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPzrv-0004Ym-6W for 40671-done@debbugs.gnu.org; Sat, 18 Apr 2020 22:39:39 -0400 Received: by mail-oi1-f178.google.com with SMTP id 8so5807420oiy.6 for <40671-done@debbugs.gnu.org>; Sat, 18 Apr 2020 19:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gjAJ8wZuVi9eUQIuBsQwLEE8e4YvN3N2soGu0HnHOFA=; b=PlASGnzDeVoFxZC4KCV2P5sfBRy78QRpWqcgyBUBnFESycx8IjfsrOuj9Q4BCnb9Y6 mIZBXAR2xPrZVO8tdrQwQH/my9sY13AQSRHq/c9+bjXKxVQ0dEL5q7S/sWaat/dtU57r WH7R+Py+vonM2/CWlJGsENFsMKIQGlL/oQF07q6nMPGIcZy8yBTT9XELph+ohdvHZQWP 5F93bHJbVsQD052fDOxpBq43GZK2dZzAzclnp8InQV33oVVwvZ6/61TKtY8rKKS8+xbI nPoQsgO7I+5Y85uMNqyKEFBDdck1uGuzsG+iipA+OKff7HHhtdjBmExOK1kmcVYxa+0G ZSgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gjAJ8wZuVi9eUQIuBsQwLEE8e4YvN3N2soGu0HnHOFA=; b=riLN+FuNoZnco+PNqeJbHQqTGk0Oa/f90u0mVO85m5oRsLmjRIcFPnXSx2ZccjkzuN s8kAQovdQBLE92Q9m/mEiNNtoqMfyC6chZuUNjpZonCojJ6/YdGXBHwt6tYdPbFDk6xE haTvo0vhAmMOeVZQxObE5+Ltyn9O/l94z5Q7US2ePy0gDjO35yanEUqBu8llKrjUHpcB G4VVA7ZIFG+iRf5RYgi6c0EJ7bt6F+Y0HpRYVGVGBZehXvA6FHEhiuur+bx8pZ7l4Bml 3ma/tU1iUGWTWAoDzrOFrqakiVHlM6ner2dt+zkvh4fgbFPG8PvFMl9SlEg6Nk7UaKwZ D/eQ== X-Gm-Message-State: AGi0PuYPxMXl/Mt8JOn62F+bFy2il0psz/VI5d+rc0grIrxV3wabAM/Y cduhWqJ8UYCK5nCmiBa0SXEA4ShOP2l2WqKljOk= X-Google-Smtp-Source: APiQypJhJ9Rixtdd+7sU6cFQVDxqt1hpkzYnXICJy3in/GoKtXuZjS9sXVJ12mtLCdICkf8h5tHFxJGW+CvhFJY7MiU= X-Received: by 2002:aca:cf4b:: with SMTP id f72mr7135342oig.177.1587263973603; Sat, 18 Apr 2020 19:39:33 -0700 (PDT) MIME-Version: 1.0 References: <87v9lzmdrw.fsf@laposte.net> In-Reply-To: From: Noam Postavsky Date: Sat, 18 Apr 2020 22:39:13 -0400 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On Sat, 18 Apr 2020 at 17:55, Drew Adams wrote: > An immutable list would be one you couldn't ever > change - it would truly be a constant. That can > be true for the result of byte-compiling a quoted > list. As far as I know, byte compilation has no special effect on mutability. Dumping does, or used to, I think that no longer happens with the pdumper. . From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 13:58: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 To: Paul Eggert Cc: mattiase@acm.org, 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873046283234 (code B ref 40671); Sun, 19 Apr 2020 13:58:02 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 13:57:08 +0000 Received: from localhost ([127.0.0.1]:45621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQARY-0000q6-FK for submit@debbugs.gnu.org; Sun, 19 Apr 2020 09:57:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59960) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQARX-0000pt-9o for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 09:57:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51649) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQARQ-0005fg-Bh; Sun, 19 Apr 2020 09:57:00 -0400 Received: from [176.228.60.248] (port=4598 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQARP-0003cN-5u; Sun, 19 Apr 2020 09:56:59 -0400 Date: Sun, 19 Apr 2020 16:56:52 +0300 Message-Id: <83tv1finob.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Paul Eggert on Sat, 18 Apr 2020 13:10:30 -0700) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Cc: 40671-done@debbugs.gnu.org, Kevin Vigouroux , > Eli Zaretskii > From: Paul Eggert > Date: Sat, 18 Apr 2020 13:10:30 -0700 > > Mattias, thanks for going through the Emacs manual and looking for mistakes in > this area. I know it was a pain to do that, since I did something similar in > parallel and it was painful for me. I used your patch to crosscheck with my > draft (finding omissions on both sides) and installed the resulting patch > (attached) into the emacs-27 branch. > > This patch should address the points that Eli raised. How do you know the patch addresses my concerns, when you didn't even let me read and comment on it? What is this rush to go ahead and push changes when there's clearly some controversy that hasn't yet been resolved? Can I somehow convince you not to do that in the future? > That is, it adds explanations of the issue (both in the intro and > the reference manual, since the issue also infects the intro), and > it attempts to change examples only when the changes are needed to > avoid undefined behavior in Emacs Lisp. As Štěpán points out, not all of the examples need these changes. Please revert the changes that aren't needed. More generally, it is IMO not enough to explain the issue in one place, and then use non-literal constructs everywhere as if the reader magically knows or remembers something that is written in a very far place of the manual. The effect is to obfuscate the manual without any explanation right there and then -- which is IMNSHO a very bad thing, methodologically, because it leaves the readers wondering what they are missing. For example, the node "Sets and Lists" now sometimes uses literal lists and sometimes non-literal ones -- without any explanation why. Likewise in "Association Lists" and "Sequence Functions". This is a step backward. We are making our manual a riddle that the reader will have to solve. That is not how good manuals are written. > @example > @group > -(delq 'a '(a b c)) @equiv{} (cdr '(a b c)) > +(equal > + (delq 'a (list 'a 'b 'c)) > + (cdr (list 'a 'b 'c))) > @end group And here you simply changed the meaning of the example: @equiv{} is not the same as 'equal'. Bottom line: the extra explanations about the danger of using literal lists in some situations are a good addition to the manual, but most of the replacements elsewhere of literal lists with non-literal ones are not -- unless we also add in each case some text which explains why we use 'list', 'cons', 'vector', etc, instead of literal constants. Please fix these deficiencies. Thanks in advance. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 17:01: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 To: Eli Zaretskii Cc: ke.vigouroux@laposte.net, Paul Eggert , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158731563011513 (code B ref 40671); Sun, 19 Apr 2020 17:01:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 17:00:30 +0000 Received: from localhost ([127.0.0.1]:45818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQDIz-0002zd-PE for submit@debbugs.gnu.org; Sun, 19 Apr 2020 13:00:29 -0400 Received: from mail1467c50.megamailservers.eu ([91.136.14.67]:58340 helo=mail268c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQDIw-0002zM-W2 for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 13:00:28 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1587315609; bh=5C6DQcFpSKwv7E+zG2Ys/RzmuumSDjsVdE/fJZ7lGME=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=rBNkKDMLD5JrFEAui/td004xOII8ffS9ET3uXOUNfDX/ifGEzihilURO0bAskD8K1 yDP6UZBqdXaKvcVRZxtwe0aZMEKbZzE5f3vbSPQCk9LSa0o06A836gg5ioS/P5Sl2y fSYEJv08mYIAYR1d6+PmhCbeobeN4Y3j0XPBu4rQ= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail268c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 03JGxtMg020306; Sun, 19 Apr 2020 17:00:07 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <83tv1finob.fsf@gnu.org> Date: Sun, 19 Apr 2020 18:59:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> References: <83tv1finob.fsf@gnu.org> X-Mailer: Apple Mail (2.3445.104.14) X-CTCH-RefID: str=0001.0A782F25.5E9C8354.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=BZ+mLYl2 c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8 a=5RbprDrcwj0rFHsqUqkA:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-Spam-Score: 1.4 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 19 apr. 2020 kl. 15.56 skrev Eli Zaretskii : > This is a step backward. We are making our manual a riddle that the > reader will have to solve. That is not how good manuals are written. Content analysis details: (1.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: gnu.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.4 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 19 apr. 2020 kl. 15.56 skrev Eli Zaretskii : > This is a step backward. We are making our manual a riddle that the > reader will have to solve. That is not how good manuals are written. Eli, maybe that is stretching it a bit? Paul's (and my) changes are far = from perfect but they did aim to do no harm. Surely we all prefer = correct to simple and wrong. Mistakes must and will be fixed, naturally. Your point about not surprising the user about inconsistencies in = examples is entirely fair, and we should definitely explain these issues = more clearly and in the right order. However, it doesn't mean that the = status quo ante was better: not only did the manual set bad examples in = many places, it even managed to warn sternly about non-constant = arguments to nconc right after an example which did precisely that. What about we add a separate section about literals of all types, why = they should be treated as immutable even though mutation currently isn't = detected or disallowed at runtime, and recommended ways of coping with = it (constructor functions, copy-sequence)? It would serve as a point of = reference for all sections describing destructive operations. There is = also a need for some cautionary text in the backquote section. I'd volunteer to write it all but won't do the work just to have it shot = down on general principles. It's not like I'm expecting a blank cheque, = but we'd need to agree on the approach first. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 19:23: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 To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158732413424870 (code B ref 40671); Sun, 19 Apr 2020 19:23:02 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 19:22:14 +0000 Received: from localhost ([127.0.0.1]:45993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQFWA-0006T4-03 for submit@debbugs.gnu.org; Sun, 19 Apr 2020 15:22:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46910 helo=eggs1p.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQFW8-0006Sr-L3 for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 15:22:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55224) by eggs1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQFW1-0007F5-Qt; Sun, 19 Apr 2020 15:22:05 -0400 Received: from [176.228.60.248] (port=4620 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQFW0-0005Mg-Ef; Sun, 19 Apr 2020 15:22:05 -0400 Date: Sun, 19 Apr 2020 22:21:56 +0300 Message-Id: <838siri8mj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Sun, 19 Apr 2020 18:59:55 +0200) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Mattias Engdegård > Date: Sun, 19 Apr 2020 18:59:55 +0200 > Cc: Paul Eggert , 40671@debbugs.gnu.org, > ke.vigouroux@laposte.net > > 19 apr. 2020 kl. 15.56 skrev Eli Zaretskii : > > > This is a step backward. We are making our manual a riddle that the > > reader will have to solve. That is not how good manuals are written. > > Eli, maybe that is stretching it a bit? Paul's (and my) changes are far from perfect but they did aim to do no harm. Surely we all prefer correct to simple and wrong. Mistakes must and will be fixed, naturally. The problem is that the changes were pushed before they could be reviewed and commented. No one said anything about meaning to do harm, but mistakes do happen, and a good way to avoid mistakes is to let peer review take its course. Rushing a commit doesn't allow to make the changes better by considering aspects that the original committer was unaware of, or where he/she is biased or lacks some knowledge or experience that others can contribute. > Your point about not surprising the user about inconsistencies in examples is entirely fair, and we should definitely explain these issues more clearly and in the right order. However, it doesn't mean that the status quo ante was better: not only did the manual set bad examples in many places, it even managed to warn sternly about non-constant arguments to nconc right after an example which did precisely that. I stand by what I wrote: the status quo ante was better. A manual is not a mathematical paper, where everything should be rigorous all the way from the first page to the last. A good manual introduces the material gradually, and makes simplifications to avoid dumping too much stuff on the reader at once. So yes, it is entirely legitimate to show simplified examples, and at some later point say that those simple examples have pitfalls, and explain those pitfalls. There's absolutely no requirement to be 110% correct everywhere in the manual, because that will make the manual hard to read and understand, and eventually will shoot us in the foot. This is, of course, my opinion. Your opinions might be different, and maybe you could convince me in some of the cases. But for this to happen, we need to talk, and you (or Paul) need to present the arguments that aim at changing my mind (or change your own). Is it too much to ask to let the discussion proceed? If these matters are important, then we should give their discussion our best shot, so that the net result is absolutely the best we could come up with -- and that means it should incorporate the different views and experiences of most or all the participants. > What about we add a separate section about literals of all types, why they should be treated as immutable even though mutation currently isn't detected or disallowed at runtime, and recommended ways of coping with it (constructor functions, copy-sequence)? It would serve as a point of reference for all sections describing destructive operations. There is also a need for some cautionary text in the backquote section. > > I'd volunteer to write it all but won't do the work just to have it shot down on general principles. It's not like I'm expecting a blank cheque, but we'd need to agree on the approach first. I don't think I understand the proposal enough to answer the question. Wed already have a section about these matters, and the additions that Paul made there are more or less uncontroversial, I think, and generally consider a Good Thing. What do you suggest in addition to that? From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 20:40: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 To: Drew Adams , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158732877832235 (code B ref 40671); Sun, 19 Apr 2020 20:40:02 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 20:39:38 +0000 Received: from localhost ([127.0.0.1]:46084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQGj4-0008Nq-71 for submit@debbugs.gnu.org; Sun, 19 Apr 2020 16:39:38 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60400) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQGj3-0008Nd-5R for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 16:39:37 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EE0B4160065; Sun, 19 Apr 2020 13:39:30 -0700 (PDT) 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 6P3Uj0Gd9iNm; Sun, 19 Apr 2020 13:39:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 11479160068; Sun, 19 Apr 2020 13:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 TcES3BQzhRZJ; Sun, 19 Apr 2020 13:39:29 -0700 (PDT) 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 CD1DA160065; Sun, 19 Apr 2020 13:39:29 -0700 (PDT) References: <87v9lzmdrw.fsf@laposte.net> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <57532862-f6ec-84b6-13af-8a8985366ff0@cs.ucla.edu> Date: Sun, 19 Apr 2020 13:39:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/18/20 2:54 PM, Drew Adams wrote: > "should be applied only to @dfn{mutable} lists, > that is, lists constructed via @code{cons}, > @code{list} or similar operations." > > That's not a usual meaning of "mutable". Your > "that is" makes clear what you mean, sort of, I > suppose. That part is clear enough, but it's > not a good "definition" of "mutable". > > It's about code that always creates new list > structure, versus code that might create new > list structure only sometimes (e.g. the first > time it's encountered). I think we're mostly in agreement here, it's just that it can be difficult to state things clearly in a reference manual. Let me try to explain a bit further. As far as Elisp is concerned, it's OK to apply destructive operations to list structures that are created only sometimes (e.g., the first time it's encountered), so long as these structures have been created dynamically by the program. That is, the key notion is not whether the program is implementing hash-consing on its own (where it's a bad idea to modify already-existing structures but is valid as far as Elisp is concerned); the key notion here is whether the program is diving into the Lisp interpreter's data structures and attempting to change those data structures on the fly (the program shouldn't do that, as the results are unpredictable and Emacs might crash). > A quoted list, which you call "constant", is in > fact mutable in some contexts. Yes, but we cannot easily document where and when those contexts might be, and it would be a disservice to our users if we tried to document what happens exactly, partly because of the complexity and partly because the byte-compiler might change in the future. Instead, we should simply say that one should not modify the data structures that quoted lists return. > An immutable list would be one you couldn't ever > change - it would truly be a constant. That can > be true for the result of byte-compiling a quoted > list. We can talk about the distinction between a "true constant" and a "constant" in an introductory section, but in the rest of the manual it's simpler to merely distinguish between constant objects (which the program should not change) and mutable objects (which the program can change). That is, in most of the manual there's no reason to distinguish between the two: modifying a constant is trouble, and programs shouldn't do it. In the introductory section we can talk about what happens if programs try to modify a constant anyway. > "However, the other arguments (all but the last) > must be mutable lists." > > "MUST" means you CANNOT do otherwise. I changed it to "should". > BTW, "a quoted constant list" is a bit poorly > worded, as well. I changed that to "constant list". > FWIW, Common Lisp doesn't talk about mutable > or immutable lists (or other objects): > > "The consequences are undefined if literal > objects (including quoted objects) are > destructively modified." > > Undefined. They CAN sometimes be destructively > modified. Yes, that's the idea I'm trying to capture here as well, with the changes I installed today. Thanks for your comments. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 20:46: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 To: Eli Zaretskii Cc: mattiase@acm.org, 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158732911732763 (code B ref 40671); Sun, 19 Apr 2020 20:46:02 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 20:45:17 +0000 Received: from localhost ([127.0.0.1]:46088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQGoW-0008WN-TT for submit@debbugs.gnu.org; Sun, 19 Apr 2020 16:45:17 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQGoV-0008W8-Cb for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 16:45:16 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0F97B160065; Sun, 19 Apr 2020 13:45:09 -0700 (PDT) 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 f-IFI7TZzF7A; Sun, 19 Apr 2020 13:45:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C5F03160068; Sun, 19 Apr 2020 13:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 GUn0JOnTNvJJ; Sun, 19 Apr 2020 13:45:07 -0700 (PDT) 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 91301160065; Sun, 19 Apr 2020 13:45:07 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <5c92a765-4502-3063-7f85-302cb1962caf@cs.ucla.edu> Date: Sun, 19 Apr 2020 13:45:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83tv1finob.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------7314F91EC47810426F7CE033" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------7314F91EC47810426F7CE033 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 4/19/20 6:56 AM, Eli Zaretskii wrote: > How do you know the patch addresses my concerns I don't know that; I merely wrote that the patch should address the point= s you=20 raised earlier. The goal was to improve documentation that was obviously=20 deficient in this area - there's no serious dispute about that. The chang= es I=20 installed were intended to be an improvement and have been found so by ot= hers -=20 if you disagree, please feel free to revert or improve them. Obviously t= he=20 documentation is not perfect in this area and further improvements would = be welcome. > As =C5=A0t=C4=9Bp=C3=A1n points out, not all of the examples need these= changes. I installed further changes that should address =C5=A0t=C4=9Bp=C3=A1n's c= omments. > For example, the node "Sets and Lists" now sometimes uses literal > lists and sometimes non-literal ones -- without any explanation why. > Likewise in "Association Lists" and "Sequence Functions". This was in response to your request to not change examples if the exampl= es=20 didn't strictly need the changes. Although I preferred Mattias's original= =20 proposal because it switched to the (list ...) style more uniformly, the = patch I=20 installed mixed the '(...) and (list ...) styles because I thought that w= as what=20 you were asking for. I installed the attached patch, which attempts to address this issue by a= dding=20 comments that try to explain why (list ...) is needed sometimes. However,= in=20 hindsight perhaps we should go back to the style used in Mattias's propos= al, as=20 it's simpler and more consistent and doesn't distract the reader from the= focus=20 of the documentation. Going back to Mattias's style would let us remove s= ome of=20 the comments that the attached patch inserts. >> @example >> @group >> -(delq 'a '(a b c)) @equiv{} (cdr '(a b c)) >> +(equal >> + (delq 'a (list 'a 'b 'c)) >> + (cdr (list 'a 'b 'c))) >> @end group >=20 > And here you simply changed the meaning of the example: @equiv{} is > not the same as 'equal'. Ah, I missed on that one. Thanks for pointing it out. I reverted that cha= nge in=20 the attached patch. As you note, it's not essential that the list be modifiable in this parti= cular=20 example. That being said, the documentation should not suggest that it's = OK to=20 use a destructive operation like delq on a constant, so further improveme= nts=20 would be helpful here if someone can find the time. --------------7314F91EC47810426F7CE033 Content-Type: text/x-patch; charset=UTF-8; name="0001-Improve-mutability-doc.patch" Content-Disposition: attachment; filename="0001-Improve-mutability-doc.patch" Content-Transfer-Encoding: quoted-printable >From 5805df74f5b919a3f67f3f7d31d6e600e1564e4e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 19 Apr 2020 13:22:10 -0700 Subject: [PATCH] Improve mutability doc MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit See Eli Zaretskii=E2=80=99s suggestions (Bug#40671#33). * doc/lispref/lists.texi (Setcar, Setcdr, Rearrangement): * doc/lispref/sequences.texi (Sequence Functions) (Array Functions): Add commentary to examples. * doc/lispref/lists.texi (Sets And Lists): Revert change to delq example. --- doc/lispref/lists.texi | 16 +++++++--------- doc/lispref/sequences.texi | 14 ++++++++------ 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/doc/lispref/lists.texi b/doc/lispref/lists.texi index f1acc85616..1125af7bec 100644 --- a/doc/lispref/lists.texi +++ b/doc/lispref/lists.texi @@ -911,7 +911,7 @@ value @var{object}. For example: =20 @example @group -(setq x (list 1 2)) +(setq x (list 1 2)) ; @r{Create a mutable list.} @result{} (1 2) @end group @group @@ -931,7 +931,7 @@ these lists. Here is an example: =20 @example @group -;; @r{Create two lists that are partly shared.} +;; @r{Create two mutable lists that are partly shared.} (setq x1 (list 'a 'b 'c)) @result{} (a b c) (setq x2 (cons 'z (cdr x1))) @@ -1022,11 +1022,11 @@ reached via the @sc{cdr}. =20 @example @group -(setq x (list 1 2 3)) +(setq x (list 1 2 3)) ; @r{Create a mutable list.} @result{} (1 2 3) @end group @group -(setcdr x '(4)) +(setcdr x '(4)) ; @r{Modify the list's tail to be a constant list.} @result{} (4) @end group @group @@ -1135,11 +1135,11 @@ Unlike @code{append} (@pxref{Building Lists}), th= e @var{lists} are =20 @example @group -(setq x (list 1 2 3)) +(setq x (list 1 2 3)) ; @r{Create a mutable list.} @result{} (1 2 3) @end group @group -(nconc x '(4 5)) +(nconc x '(4 5)) ; @r{Modify the list's tail to be a constant list.} @result{} (1 2 3 4 5) @end group @group @@ -1267,9 +1267,7 @@ after those elements. For example: =20 @example @group -(equal - (delq 'a (list 'a 'b 'c)) - (cdr (list 'a 'b 'c))) +(delq 'a '(a b c)) @equiv{} (cdr '(a b c)) @end group @end example =20 diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi index 62d60156fb..1cb0d05cc7 100644 --- a/doc/lispref/sequences.texi +++ b/doc/lispref/sequences.texi @@ -183,11 +183,11 @@ for other ways to copy sequences. =20 @example @group -(setq bar (list 1 2)) +(setq bar (list 1 2)) ; @r{Create a mutable list.} @result{} (1 2) @end group @group -(setq x (vector 'foo bar)) +(setq x (vector 'foo bar)) ; @r{Create a mutable vector.} @result{} [foo (1 2)] @end group @group @@ -278,7 +278,7 @@ Unlike @code{reverse} the original @var{sequence} may= be modified. =20 @example @group -(setq x (list 'a 'b 'c)) +(setq x (list 'a 'b 'c)) ; @r{Create a mutable list.} @result{} (a b c) @end group @group @@ -320,7 +320,7 @@ presented graphically: For the vector, it is even simpler because you don't need setq: =20 @example -(setq x (copy-sequence [1 2 3 4])) +(setq x (copy-sequence [1 2 3 4])) ; @r{Create a mutable vector.} @result{} [1 2 3 4] (nreverse x) @result{} [4 3 2 1] @@ -374,7 +374,7 @@ appears in a different position in the list due to th= e change of =20 @example @group -(setq nums (list 1 3 2 6 5 4 0)) +(setq nums (list 1 3 2 6 5 4 0)) ; @r{Create a mutable list.} @result{} (1 3 2 6 5 4 0) @end group @group @@ -1228,7 +1228,7 @@ This function sets the @var{index}th element of @va= r{array} to be =20 @example @group -(setq w (vector 'foo 'bar 'baz)) +(setq w (vector 'foo 'bar 'baz)) ; @r{Create a mutable vector.} @result{} [foo bar baz] (aset w 0 'fu) @result{} fu @@ -1262,6 +1262,7 @@ each element of @var{array} is @var{object}. It re= turns @var{array}. =20 @example @group +;; @r{Create a mutable vector and then fill it with zeros.} (setq a (copy-sequence [a b c d e f g])) @result{} [a b c d e f g] (fillarray a 0) @@ -1270,6 +1271,7 @@ a @result{} [0 0 0 0 0 0 0] @end group @group +;; @r{Create a mutable string and then fill it with "-".} (setq s (copy-sequence "When in the course")) @result{} "When in the course" (fillarray s ?-) --=20 2.17.1 --------------7314F91EC47810426F7CE033-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 21:02: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 To: Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873301151796 (code B ref 40671); Sun, 19 Apr 2020 21:02:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 21:01:55 +0000 Received: from localhost ([127.0.0.1]:46097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQH4c-0000Su-Ri for submit@debbugs.gnu.org; Sun, 19 Apr 2020 17:01:55 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:33850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQH4Y-0000SR-TN for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 17:01:51 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03JL0XUn181030; Sun, 19 Apr 2020 21:01:36 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=OcTPeYIu+ioEKL/gTqvKtysJWEJee/iijT/eqJOJFZA=; b=zVI3cdaoj1RcRYzq08jdjX19lfyo/qMxxNYoALFE9C23PB9Dt9iSTq8bNiljo2ikL36i GZP7n8Tsx8IGGeBzOg99/UCzVQp0mi1PgeP4oVmZgbGArb7Fygk3R7pEhcbriEEJF3Dq MwMC3L9iAPtLYZQQg216jvDhUme9hjAZlzq4/q7Su8hiTt8BrRpIXAw3p2PGad/N4BCR zIEZ3smRIiTshMGVOLtUxKxGkGybMQ9k/c0FDunkXzQ+M5sPyeP4wliP5TIwZQUctGcz yqbE+nVZLKwbsAJUlc8RSkaf4OKBH529I4k+WBm3Ok0rGezCMU8iqLeBLkxM9HMhDpYU ig== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 30ft6mv2jn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 19 Apr 2020 21:01:36 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03JKvJtC133958; Sun, 19 Apr 2020 21:01:36 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 30gb8uqhb7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 19 Apr 2020 21:01:36 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03JL1VUK005715; Sun, 19 Apr 2020 21:01:32 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 19 Apr 2020 14:01:31 -0700 (PDT) From: Drew Adams References: <87v9lzmdrw.fsf@laposte.net> <57532862-f6ec-84b6-13af-8a8985366ff0@cs.ucla.edu> In-Reply-To: <57532862-f6ec-84b6-13af-8a8985366ff0@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)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=658 adultscore=0 bulkscore=0 suspectscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004190180 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1011 mlxlogscore=724 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004190180 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. 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. You are once again confusing things for readers, I think. Something you probably _should not_ change is not necessarily a constant. (And the converse isn't strong enough - you simply _cannot_ change a constant.) 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. That's the wrong message. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 21:03: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 To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873301721909 (code B ref 40671); Sun, 19 Apr 2020 21:03:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 21:02:52 +0000 Received: from localhost ([127.0.0.1]:46102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQH5Y-0000Ui-5X for submit@debbugs.gnu.org; Sun, 19 Apr 2020 17:02:52 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQH5W-0000UV-9K for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 17:02:50 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3AC0E160065; Sun, 19 Apr 2020 14:02:44 -0700 (PDT) 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 koMqF3tLf7nu; Sun, 19 Apr 2020 14:02:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E2FFE160094; Sun, 19 Apr 2020 14:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 v7vEA_e79U5D; Sun, 19 Apr 2020 14:02:42 -0700 (PDT) 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 B415816008E; Sun, 19 Apr 2020 14:02:42 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> Date: Sun, 19 Apr 2020 14:02:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/19/20 9:59 AM, Mattias Engdeg=C3=A5rd wrote: > What about we add a separate section about literals of all types, why t= hey should be treated as immutable even though mutation currently isn't d= etected or disallowed at runtime, and recommended ways of coping with it = (constructor functions, copy-sequence)? It would serve as a point of refe= rence for all sections describing destructive operations. In my recent patches to the emacs-27 branch I added a section "Constants = and=20 Mutability" that discusses many of these issues. It's a fundamental topic= so I=20 put the new section into doc/lispref/objects.texi, and cross-referenced i= t from=20 the destructive-operation sections. I didn't think of recommending ways of coping with it, and that's a good=20 suggestion. I'm not sure that the coping-mechanism discussion belongs in=20 objects.texi, though, as it's pragmatic rather than fundamental. > There is also a need for some cautionary text in the backquote section= . Yes, my recent patches added a brief note there. > I'd volunteer to write it all but won't do the work just to have it sho= t down on general principles. I know the feeling. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 21:12: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 To: Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873307012660 (code B ref 40671); Sun, 19 Apr 2020 21:12:02 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 21:11:41 +0000 Received: from localhost ([127.0.0.1]:46107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQHE5-0000gq-1F for submit@debbugs.gnu.org; Sun, 19 Apr 2020 17:11:41 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:39150) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQHE2-0000gd-HZ for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 17:11:39 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03JL8m5r002256; Sun, 19 Apr 2020 21:11:30 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=1YX7ITQ4xFwuAfKuyll0blhipAAQJMWiehD/NPWc4tU=; b=iyZIlnF/+WPFsi3aBwCAKeKceZbU44GBpKaVH7/5BdKkqxKcYFKK4/MwUtMB8KSZJR9a MMVEyr2OSx3MNLmLbo4OozYDgBj2g1gya/6XzPWR9KPXZMI6k1TRQaoFGDbzQIvRCaJM gQitQP7pmknFuyFxRWKqJc8H3RQFFS2Yk2CbwvBfetgF0qBG43CmMEMB84HsvSCAlmYE DxXSAGNfYVD+jFZYLe5LmIBekxURspYhhtAbdomIHpDM6EJFxL5ZSySEE4sxnPDhb+w4 KMNw0OV3i6qSaDcygu3aW0zPzWLwSzbII5JAAENOaEsWC0kTGrLg/lmsAVWWVnNMhviS Ug== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 30ft6mv2yn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 19 Apr 2020 21:11:29 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03JL7gAo151537; Sun, 19 Apr 2020 21:11:29 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 30gb8ur15v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 19 Apr 2020 21:11:29 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03JLBPVi022470; Sun, 19 Apr 2020 21:11:25 GMT MIME-Version: 1.0 Message-ID: <8c18a634-23a6-4b5e-98a9-58e80d517fb9@default> Date: Sun, 19 Apr 2020 14:11:24 -0700 (PDT) From: Drew Adams References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> In-Reply-To: <527dc4b5-3176-38b5-f2c1-1483ffc814a1@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)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 bulkscore=0 suspectscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004190181 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 mlxlogscore=999 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004190182 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > In my recent patches to the emacs-27 branch I added a section > "Constants and Mutability" that discusses many of these issues. See my previous reply. It's not about (what you called) constants and mutability. Misleading, and unclear, IMO. > I didn't think of recommending ways of coping with it I don't think that's needed. That is, I don't think there's any such "coping". What's needed is to make clear to users _what_ happens, and its effects; that's all. With that info, they can do whatever's appropriate for them in any given context. But it's good to show an example of a gotcha, to help make clear _what_ can happen and why. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects 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 To: Drew Adams , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873310053136 (code B ref 40671); Sun, 19 Apr 2020 21:17:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 21:16:45 +0000 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 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 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) 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) 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 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) 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) References: <87v9lzmdrw.fsf@laposte.net> <57532862-f6ec-84b6-13af-8a8985366ff0@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <127084e8-c62a-ec8c-5d40-8c4280861519@cs.ucla.edu> Date: Sun, 19 Apr 2020 14:16:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 21:59: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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873335026853 (code B ref 40671); Sun, 19 Apr 2020 21:59:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 21:58:22 +0000 Received: from localhost ([127.0.0.1]:46126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQHxG-0001mT-AR for submit@debbugs.gnu.org; Sun, 19 Apr 2020 17:58:22 -0400 Received: from mout.web.de ([212.227.17.11]:40573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQHxE-0001mH-KU for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 17:58:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1587333472; bh=kgapEzjr0lj5CCDu2usVEd4nOo9Iw5iTcfcVdI40Cx8=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=P6CAoR2TFN30cqaSJbXk0djW+Vo92jr2EgdaqELnj9Xdho+80DVKJ6RBMDt53S/rU nEYo4bxRmMWnt2HtQGrILohPDx+GyVgFDIDWPfWbWaBy1n638jLQR3M5CudqLbXel6 rT5Ke+hj3b8zPQGB59efZ0MHLUGEsiKJcfYymSaQ= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MCqoJ-1jZwqh1WmB-009dfQ; Sun, 19 Apr 2020 23:57:52 +0200 From: Michael Heerdegen References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> Date: Sun, 19 Apr 2020 23:57:53 +0200 In-Reply-To: <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> (Paul Eggert's message of "Sun, 19 Apr 2020 14:02:42 -0700") Message-ID: <87k12b6sv2.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:xVOVSX0wfhewDNT53oTuRkl0/80RoKo76JUO7GuDrGuE2JZ6DBG PszKQuwEXiV2PRDI2gXrTaxk/D3wqbRzl6C/GwVnRXZ/qdbH33c7Bdc/+r0XeEYDmiYbtvU KBjWAPnMpCeBMGIq3iKo252jZeS/Ali95HbfqJ06XZEzbqw1O4XcIGcRNyTEs2KZpW1Nnzl F4P5zZmpKL9xtkAMs4Qag== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:2MQRAxcF9b4=:aNgA2eG4wMCBi2nzYdPsEa V3wyx7uZ5tZdolpfdZ4d6N88Xy8+GE9dFPfkCejtNsg8fcRMOy5WmhT/XLBSYWLcQFHLu8w5S 8LdMIR2OEESQA//KyCVsC783k9N1TDicB8RFWII7Jh/2DJvRf4D5A2TdVN1zeh5XbcfxsPfy+ cChS3q2mexFpapOaGHIDEbfaaXMipqiBr/m2iwiQMJnos2GgbeYIbpKNXSAQeuyS5x8lv7WEp DXvbRRzFMIl7bVHmCvVSNILZ7vxucGaITs+fXWTjoFmOfwEY2c0/9x096m1Fl/2ludPvmtHNS YEoTaPsugxZVuJFjeEIDZN/QSNGIYkNQWzzifg1Fh1A0PoMsbygYT5wQkFjKSvxMFREJ2xcay Lkd3LWN19US9f5j65kazdOGahceWTsFvUelxAgo43zl9h3EiQIvifqGExqzuIuxnMgXeMXHif jtStod86hIY+EeQGuUDRW5XiScZWFh0El5qrJjtTR7xVf57G5/02u2hc1Tabi8zHe4wREWF2S ciDOIeHbuKm52IP70c4fnAF197k+tnJ6CYwVyMM/h88QRswm2jFTPMxpu5sGXubdW4MM11dfO 9ptCcLtt3vnIYH/1VBG3tt/91eP3qF6915S7mJpVphzPVZGSMrdRszESnP+FM7TCVEU2W7dJS Wnh1XLLorM60mCJIX95m3DO7Qyq+lpQjXK57f33Bacq/o7/Kk5FZsO9RUWlGf+L/Tnkb8qmCJ Qyy1IBdX/JmvViRi3vXrbz6ErMPGd3vSmJyaO+CidDPo/LGmLwjaE8IYrnSWFDzoCoV/dDnWo ootbC6qlEctRpbTxqceMISaO9OHLZps1+Z3mlRuEQgXobBZf0rUCAOlmNxshhZxFFzi2m+YK7 /q5v30iZKya2f5LpcGAvIhtLDb7Js6JyWwraEHp5KK5yRqI4rii3AbFhZpzruXYSGKGsKhqii SNXp5P3lhk4pGm5Wao8u8ymRrTH209RARb85XpyS4dQZnQFGz1+gwO8L4SvyD5+Ch9aSDTXqi 2B4x6CSw90ipbwi+OYtuKfrkgUrknWbyjb0t3Y+eYpxaXPkokz+EfOcNYHQ5GWwTC1lfIW+Ea nRPKvtIFShDFePJKO6Wmb+q9nRG9gLNS91lEI4O6g3+bFTaE8vvShqlZqnZoCPtZMrudOhYhO kdX6wL4UcY7ilIDWrdOV3HiC9I9o33m1F70zvFMFFmtEiUDhg2CM8x468zuhLCO0nhgzEMk93 0G9yL4Wjst84rpzhK X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hello Paul, I had a quick look at your changes. I agree that it would have been better to discuss before you start to install what you think you like. Some things add more confusion. Before your changes the manual used the term "literal" objects, now you added a different wording "constant" vs. "mutable" that describes more or less the same thing. Then some things you added are just wrong, at least in the generality you word them. As Drew said, `quote' doesn't always return constant objects, the special form just returns the OBJECT, whatever it is, when it is evaluated. Or: | Vectors written with square brackets are constants and should not be | modified via @code{aset} or other destructive operations. (let ((l (list 1 2 3))) (let ((my-vector `[,@l])) my-vector)) What does this sentence tell me about the vector I constructed? We should really be super careful with these changes. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects 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 To: Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873350929348 (code B ref 40671); Sun, 19 Apr 2020 22:25:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 22:24:52 +0000 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 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 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== 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 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 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 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 MIME-Version: 1.0 Message-ID: <566aa1bf-444d-4cff-aed8-5b83fcd60107@default> Date: Sun, 19 Apr 2020 15:24:24 -0700 (PDT) From: Drew Adams References: <87v9lzmdrw.fsf@laposte.net> <57532862-f6ec-84b6-13af-8a8985366ff0@cs.ucla.edu> <127084e8-c62a-ec8c-5d40-8c4280861519@cs.ucla.edu> 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)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > >> 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. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 22:42: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 To: Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158733607710919 (code B ref 40671); Sun, 19 Apr 2020 22:42:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 22:41:17 +0000 Received: from localhost ([127.0.0.1]:46177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQIcn-0002q3-2n for submit@debbugs.gnu.org; Sun, 19 Apr 2020 18:41:17 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44302) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQIcm-0002pr-7g for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 18:41:16 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AE3E2160065; Sun, 19 Apr 2020 15:41:10 -0700 (PDT) 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 VLSSB9ph0T34; Sun, 19 Apr 2020 15:41:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DFF6D16008E; Sun, 19 Apr 2020 15:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 sGTW3TdH8mvB; Sun, 19 Apr 2020 15:41:09 -0700 (PDT) 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 A6936160065; Sun, 19 Apr 2020 15:41:09 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> Date: Sun, 19 Apr 2020 15:41:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87k12b6sv2.fsf@web.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/19/20 2:57 PM, Michael Heerdegen wrote: > I had a quick look at your changes. I agree that it would have been > better to discuss before you start to install what you think you like. Yes, in hindsight I suppose you're right. If you like I can revert the changes now. > Before your changes the manual used the > term "literal" objects, now you added a different wording "constant" > vs. "mutable" that describes more or less the same thing. Thanks, I hadn't recalled that use of "literal object" (in the Equality Predicates) section. Although the two notions are related they're not identical. For example, the reason one shouldn't modify byte-code objects is not the sharing issue mentioned in Equality Predicates: it's because doing so can make Emacs crash. That being said, it would be helpful discuss the two notions in a unified way rather than separately, as is the case now. > Then some things you added are just wrong, at least in the generality > you word them. As Drew said, `quote' doesn't always return constant > objects, the special form just returns the OBJECT, whatever it is, when > it is evaluated. It depends on what one means by "constant" objects. If we uniformly changed that word to "literal" would that remove the objection? For example, although byte-code objects aren't normally what one would think of as being "literal", we could simply define them to be "literal". > | Vectors written with square brackets are constants and should not be > | modified via @code{aset} or other destructive operations. > > (let ((l (list 1 2 3))) > (let ((my-vector `[,@l])) > my-vector)) > > What does this sentence tell me about the vector I constructed? Nothing, just as the documentation for splicing also says nothing about that vector. These are both deficiencies in the documentation that should get fixed (and in some form the deficiencies both predate the recent changes). From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 22:52: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 To: Drew Adams , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158733667711796 (code B ref 40671); Sun, 19 Apr 2020 22:52:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 22:51:17 +0000 Received: from localhost ([127.0.0.1]:46182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQImT-00034C-1X for submit@debbugs.gnu.org; Sun, 19 Apr 2020 18:51:17 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45276) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQImR-00033z-Jy for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 18:51:16 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 95EA8160065; Sun, 19 Apr 2020 15:51:08 -0700 (PDT) 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 XHWGHEavnVDw; Sun, 19 Apr 2020 15:51:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D75F716008E; Sun, 19 Apr 2020 15:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 LoQkxSzTlUY2; Sun, 19 Apr 2020 15:51:07 -0700 (PDT) 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 A7A61160065; Sun, 19 Apr 2020 15:51:07 -0700 (PDT) References: <87v9lzmdrw.fsf@laposte.net> <57532862-f6ec-84b6-13af-8a8985366ff0@cs.ucla.edu> <127084e8-c62a-ec8c-5d40-8c4280861519@cs.ucla.edu> <566aa1bf-444d-4cff-aed8-5b83fcd60107@default> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sun, 19 Apr 2020 15:51:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <566aa1bf-444d-4cff-aed8-5b83fcd60107@default> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/19/20 3:24 PM, Drew Adams wrote: > Don't say "constant". Say "don't try to change it". That's too long and awkward a phrase for use in lots of places around the manual. We need a simple noun phrase to describe the concept; this is Documentation 101. One possible substitute is "literal object", as Mattias pointed out. Another possibility is "immutable object". Perhaps others might be better. > The only cases that are problematic are those where > you can think your code modifies something (anew) > when in fact it might not. No, that's not the only issue. If you modify some of these "constants" (or "literal objects" or whatever term you like), the behavior is undefined: Emacs can crash or remove your home directory or whatever. There is no checking. > 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. I don't see that false impression being given. But if it is being given, presumably the problem could be fixed by appropriate wording changes. Specific suggestions welcome. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 23:47: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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158733996516792 (code B ref 40671); Sun, 19 Apr 2020 23:47:01 +0000 Received: (at 40671) by debbugs.gnu.org; 19 Apr 2020 23:46:05 +0000 Received: from localhost ([127.0.0.1]:46239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQJdV-0004Ml-2G for submit@debbugs.gnu.org; Sun, 19 Apr 2020 19:46:05 -0400 Received: from mout.web.de ([212.227.15.14]:51615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQJdS-0004M1-QZ for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 19:46:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1587339944; bh=2DRC0RhHd76eJFu2yqraSpHxy0C2Tj/TsImUkOEyqlM=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=RouzYLcNjp13b+ZZdLdwMz3G1FMXqRU/brIpzMQrsC0KTZK02SRDGzT94sBdA2dIj fzIOCS11x6g6FFjcaNPTJG6yaocCBGUtfWqFABj3fPxr64ofqjsl5txQF7+q8vrgwb QsqpgeaQEnfaA1L90CTPmREf9Z+zBD1PC4ctFHUc= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MQ6KJ-1jMkzz0jUR-005Elw; Mon, 20 Apr 2020 01:45:44 +0200 From: Michael Heerdegen References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> Date: Mon, 20 Apr 2020 01:45:46 +0200 In-Reply-To: <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> (Paul Eggert's message of "Sun, 19 Apr 2020 15:41:09 -0700") Message-ID: <87a7376nv9.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:BW9LeeV77Sm9P+LUrCu+9WG0hBCrrAWVP+IAgmV0eszpuMHSpEg jhSvX9RPZ1R65V5hLB0aj/vztzEJG5FhWkp6UMMxgZEjvyl1sKS6guDBqjmsZ/n4kXdHhpR 2AtuGbd3/ksMaCQ9Y4NU3NsKk7brclSkmzy+DDbT5XmP5mw62pwz8w2PQMRxbXx9osrzKS7 E1SiAumxDbHpSRtSolD5Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:DdgBk41X4IA=:31FQoh6lzLh0jv6e2XAWPK rJSejp6+HW0P1pWgfgZO43z2IBhyu5jO91Wo2pHWaRtUAZNM5U6em0EIcGD7mgpARCEzimZSY JE99npmjZuUYTU9qviE+6W8CqZFw3QiuWVge9P82aIuDLLaesQo0kfrF7PJIXiNXqSBdYuCk6 p/eC7dXoJmupygZk7MdG+NAB9rdC/OFn151iCJ6SdAoGWFN90ZU1UEn5NmDSw5NVsUOVA7WUx QQQJ2btnCKOy9u7clSQ9mPMYncx4g7TqpZteVv3mtoR+j5kjjnlq2Ri9wmiGSKItfgHPqG3P5 86J3TnwOHn1L5ODhlyVsqLYZnutWd7v+7XJZI1qHOFm7pYNf5PDr1ttV7ODtKYFLSfVuHegCc uJs1yeOmaZikzsEeaUE6S76aLPMuMBYt+B1QqaQoIJ+G6iyb1ihalL7VU1MA+RFQxEnRPNzdi asFhUoZDQtyjPQF8SvyS8lECjwI9O5PpegEfoLipCqvJ5IyGsTrEEbZj01lTGe9q1W1Nwu+tH qMbWTnj74UUlNsVLHCzORdpxv9+pRvyKhM+aOuzLrnTPa30J0CpdYpomu6U24ULDWOagPf0BS YxBSJrkpvUPtpwUCiyWRqB2Jsbaxh/KsvAWmrqA5M6TWlEjmDV47PpOmVURt71gelHhhzjcc2 knp79PBgAgAM2r1VcVF2iCaJt3FFldxYlaF1yTdCoesztoJxMOXLb5aAuG8emWgKwOimd5xa0 ZuS2Mwm0LKwjriTJfYeZWMI2JUIftJ7SxEQPjiB12EfEj34ftE/CZImbbtHDSedNY9VAFVB03 k+tj3EosvUV4YjquyGobDAXVUhUEXoQ2/epLiJC5UZeV9xvsSDammVl0KC4Q1uaafilwVD/Jd WH4VAOtpXikYa9tdTK+kQn4LtflyslUMAhAJlST+pvZvpn7kT5mys2K1Fw1pJuH7suzmtb6kt QP+JhnTJSUq/mw0b1x8PKHzC5kSI+UNz9aNS4VzZprYUwYO8KP5u236UX0Q9LQ+Ij22L8dq9S mb1fwWpmxyVB5jaHIZwBKIumRoAP0vPgBYwRolrspGtOfJSC5J/dSJwJN+pRWc1kXhN3bHIpg 4mLLhB9MyAmsx6Pc51L70FUqSodr2Az5GLU+jXyU2uZOcSeB2OO1bo9M04E5sb5Y8TG1q8V/9 eRwqeJ0sSYI0x6cN2kovLqbMpB8ppsZxSC7NaCADRMD9Nm3h8s076h84DZUWL6FF678b+kRYy iw9w0LOBTNv4X4w7/ X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > Yes, in hindsight I suppose you're right. If you like I can revert the > changes now. I can't estimate, for me it is enough if you are willing to revert if there is no consent and we discuss all of this now. > > Before your changes the manual used the > > term "literal" objects, now you added a different wording "constant" > > vs. "mutable" that describes more or less the same thing. > > Thanks, I hadn't recalled that use of "literal object" (in the > Equality Predicates) section. Although the two notions are related > they're not identical. For example, the reason one shouldn't modify > byte-code objects is not the sharing issue mentioned in Equality > Predicates: it's because doing so can make Emacs crash. > That being said, it would be helpful discuss the two notions in a > unified way rather than separately, as is the case now. I would like to leave the suggestion of a good wording to someone like Stefan, feeling not competent enough myself. I have just the feeling sure if you simplify too much. Lisp has reading, compiling, evaluation. When the reader reads something like '(x y z), the (x y z) already produces the literal thing because the reader transforms it into an object, contrarily to creation of objects at run-time. The compiler can handle it differently. That's the main difference. The quote comes into play when the thing gets evaluated. When you evaluate the expression, the literal is returned. It could also end up as part of a program, which was the pitfall case in the initial report. > > Then some things you added are just wrong, at least in the generality > > you word them. As Drew said, `quote' doesn't always return constant > > objects, the special form just returns the OBJECT, whatever it is, when > > it is evaluated. > > It depends on what one means by "constant" objects. If we uniformly > changed that word to "literal" would that remove the objection? For > example, although byte-code objects aren't normally what one would > think of as being "literal", we could simply define them to be > "literal". No, that's not (only) what I mean. Maybe you should remember how quote is used in `defmacro's for example? Generally it's just a mean to prevent evaluation. In your examples this returned the literal notated after the quote, but it can be anything. Or - about what do you speak? The part of the program being quoted, or the thing "behind" the quote when the program is executed? When you describe the return value of quote, the special form, in the docstring, you are speaking about the latter, and then this is wrong, the return value is the arbitrary OBJECT. E.g. (let ((l (list 1 2 3))) `',l) ==> '(1 2 3) If you evaluate this (the return value is a valid expression), `quote' returns a list, but it's not a list literal. But if you try to modify what the reader constructed after reading ",l", also a list (\, l), you'll probably get a problem. As a special case, quote can be used to create lists because Lisp programs are lists and use list notation anyway. But that's only one way of using it. > > | Vectors written with square brackets are constants and should not be > > | modified via @code{aset} or other destructive operations. > > (let ((l (list 1 2 3))) > > (let ((my-vector `[,@l])) > > my-vector)) > > What does this sentence tell me about the vector I constructed? > > Nothing, just as the documentation for splicing also says nothing > about that vector. One could read your sentence as suggesting that `my-vector' would be constant because square brackets are used to construct it. This was an example to demonstrate where your wording is too vague in my opinion. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2020 00:25: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 To: Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158734229020086 (code B ref 40671); Mon, 20 Apr 2020 00:25:02 +0000 Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 00:24:50 +0000 Received: from localhost ([127.0.0.1]:46251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQKEz-0005Du-Sh for submit@debbugs.gnu.org; Sun, 19 Apr 2020 20:24:50 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQKEx-0005Dg-JR for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 20:24:48 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8349E160065; Sun, 19 Apr 2020 17:24:41 -0700 (PDT) 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 V3kz08ex-MS4; Sun, 19 Apr 2020 17:24:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A4CB5160079; Sun, 19 Apr 2020 17:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 dOOh4wMpyTWT; Sun, 19 Apr 2020 17:24:40 -0700 (PDT) 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 72558160065; Sun, 19 Apr 2020 17:24:40 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> Date: Sun, 19 Apr 2020 17:24:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87a7376nv9.fsf@web.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/19/20 4:45 PM, Michael Heerdegen wrote: > I have just the feeling sure if you simplify too much. Lisp has > reading, compiling, evaluation.... Yes, it can be complicated under the hood. The current section attempts to document this conservatively, saying "If your program does this it'll be safe." It does not attempt to document much of what happens if you step outside the "safe" boundaries (i.e., if you attempt to modify "constants" - to use the current terminology). One can indeed imagine more-detailed documentation about what happens if you modify constants. However, I didn't have the time or inclination to document the details there, and on the whole I think this was the right decision. It's not a win to greatly complicate the Elisp documentation to cover iffy edge-cases that code shouldn't be exploring anyway. On the contrary, we should leave things unspecified in this dangerous area, to give future implementers more freedom to improve Emacs. > (let ((l (list 1 2 3))) > `',l) > > ==> '(1 2 3) > > If you evaluate this (the return value is a valid expression), `quote' > returns a list, but it's not a list literal. Sure, but one shouldn't be modifying that list. Once you hand a Lisp object to 'eval', modifying that object later ought to be a no-no even if the interpreter happens to do something non-crashy now. Otherwise we're placing too many constraints on the Lisp implementation (which can crash even now if you play this sort of game). >>> | Vectors written with square brackets are constants and should not be >>> | modified via @code{aset} or other destructive operations. >>> (let ((l (list 1 2 3))) >>> (let ((my-vector `[,@l])) >>> my-vector)) >>> What does this sentence tell me about the vector I constructed? >> >> Nothing, just as the documentation for splicing also says nothing >> about that vector. > > One could read your sentence as suggesting that `my-vector' would be > constant because square brackets are used to construct it. This was an > example to demonstrate where your wording is too vague in my opinion. OK, how about if we append the following sentence to that section: As an exception to the above rules, a vector within a backquote construct is not considered to be a constant if it contains a substitution or splice. That is, the backquote causes the vector to (a) not be considered a constant, (b) be newly created each time the backquote is evaluated, and (c) mutable. The (a) and (b) parts fix problems that were already there in the longstanding documentation; the (c) part is new. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2020 00:54: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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158734402922690 (code B ref 40671); Mon, 20 Apr 2020 00:54:01 +0000 Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 00:53:49 +0000 Received: from localhost ([127.0.0.1]:46275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQKh3-0005tt-Ex for submit@debbugs.gnu.org; Sun, 19 Apr 2020 20:53:49 -0400 Received: from mout.web.de ([212.227.17.11]:50995) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQKh1-0005tg-Cw for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 20:53:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1587344013; bh=mb3Jt+WREmmwhpjl4oRZJ9rehXlROydxoTn41CcJigo=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=GN9fxXEpz7VIu4CHuJVi3j2H39OHycRp6HwE/vnWtQRdvfYK169qlbmyVA8FmvU7x wUfWNlamOqt4bBXzwAp7RtgeFsjYmVDcdxievA1VtbXatCEmx4v7cYQN7ZnGWa1Nmk o2WBUaO6u/xUaZTPR2cwQHrxBeFIhwk/wr8xDkSw= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MUncu-1jivNh2erM-00Y6xQ; Mon, 20 Apr 2020 02:53:33 +0200 From: Michael Heerdegen References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> Date: Mon, 20 Apr 2020 02:53:35 +0200 In-Reply-To: <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> (Paul Eggert's message of "Sun, 19 Apr 2020 17:24:40 -0700") Message-ID: <87o8rnasfk.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:jTXp5c3jUp7HCPlE/kRvHrRV4NuYRZghaN8eaxCTU48lHxpZ4Qy HzXKQR2vpyPBfYfcSv4Wg/hW2uA15n9jzPJue28Y60PWDL8KPbyDC44QZz08T7bNRUiuI7J aicG3DBZDENQjSjMyJztTZOQOAbNm3HyYE5t4M2ZRK6cbkDPCAVU0DZpOqELDLkCbzd9jbL nt+q4TlGi7lwgeVZcTRqQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:96YCkO5W3Ls=:ZmgQxAOhAyAg3TuVrZlzSp 90NCQ1BQwfGrPvEH01UYTPpcG+AqiNWXP3rnRmN9C0aJDcqoxn6NBsXMO2D929iEXwAAkywW5 Yj7NBNHc4IVywVfLf+SI2crsrHnYZtpZs7tY3d8pEYTHSYChjRidPCHgDqPnwYqB2IGm64Ret QyFfsugK3DnpeyHbJIs2HERi6HkX36AspD/g1YNIiBWdAsGkxcaP6VT8C4VlBUuWWZ7ARHX95 zb9UXW8leqDmQijAcweWc4944jKs7TpVy5U3j1Q9F6q6bLXsQjGHR5HJ9Ny2YkjWyBfujSnaT 4U6CFZ4MXRGypHtU/8tnkrlZiGqU547GkP6nlmbdiFd1thz94Zeqg7ZIe0gjDLFByX7A0ROhI MSGWZ6iIWc1Emi8R8bpXJqAtpRAx9Ij61Mx4VSmEpqKm3f95u9YieXrm+3/8DZrTQ+Ij4MHwR X56Q5D1gBiKbIstVHdevoPi7xdHw3i4XCtMZCcCWBg+PZ/x5cRa1VIi1rWTr6eOUmbQVWU4HQ bXPAIrwj5Hp7Kc8x2VR1jMdUC7NIFYxTb+ylkTrEru/bbH/W584RCadQL/oIjHu+MNocaLBKU 3UTyjLuEMkyqGfx1/qpPMBcK3+HnuDcPdsskygb2cHaVYg/TgFVCzC8Cb2mb0hQFQfIWCbMXy WH9ygDV3WPIW7kzD3I3zF6j80hCdOEvhseoCBxDgNdwcWsKdY3A3zgEwcLnzC8Hf5ZDSsw0Qq OGCLgulA9iRTVTbDaWPPv6V3Za8RwhmI3mkLbJa+Us1IlIbpXSu7/UR788jGDlq3hIe0MTo+Z 1uxgOsIzP5Lc/SL2FH+zxazqvm49Ub6xVZjyBG3Wm/bPnvxDlcjvfBUFTA9eSMym0OMjyVHkh NJHjPVm7e/9+Qst3O+lkJFUGIhaQrkDWMtiJnslI1DEM6tL+zLwtL0vihFLq1LghGK4OAcWst i+A2xuCyDEZPq+pipfr6PS3cvs0aYMNNLUGKTMe3Pgrgq5L42IXI5g6J/AvUtl6VBzar8k6kh St3s86olxMGRdKevmCXkTaU1TeenSm3JtC02u+6WPw63R/GaOqVbd613HBzFNcx9poyKLp4OU y8QXq66bbiHlyxGs95bUVe7d7JStRrKB9v4ASiN0ur2KyUdv9lm0SwZBquf2ASGZDzGtWqnos l/+f82bV9t1TaZwfv3eWjw1ja9gqmPX/1NT6An23k8YKc9VdazWDhPgCnjeUe2z7Fo+XaKnYA UyiDoKAm/bvgbuZMZ X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > > (let ((l (list 1 2 3))) > > `',l) > > ==> '(1 2 3) > > If you evaluate this (the return value is a valid expression), > > `quote' > > returns a list, but it's not a list literal. > > Sure, but one shouldn't be modifying that list. Once you hand a Lisp > object to 'eval', modifying that object later ought to be a no-no even > if the interpreter happens to do something non-crashy now. But I can modify the list before handing it over to `eval', e.g. replacing the `1' with `cons'. And even when I eval the original list, I get just the same l as before: (let ((l (list 1 2 3))) `',l (eq l (eval `',l))) ==> t. AFAIU the problematic entities are the literal lists created by the reader and the compiler. > >>> (let ((l (list 1 2 3))) > >>> (let ((my-vector `[,@l])) > >>> my-vector)) > OK, how about if we append the following sentence to that section: > > As an exception to the above rules, a vector within a backquote construct > is not considered to be a constant if it contains a substitution or splice. > That is, the backquote causes the vector to (a) not be considered a > constant, (b) be newly created each time the backquote is evaluated, > and (c) mutable. The (a) and (b) parts fix problems that were already > there in the longstanding documentation; the (c) part is new. Here your perspective becomes complicated. The Lisp reader reads the vector [,@l] while reading the program. That vector is never used by the program, because already the expansion of the code does not include a vector any more: (macroexpand-all '(let ((l (list 1 2 3))) (let ((my-vector `[,@l])) my-vector))) ==> (let ((l (list 1 2 3))) (let ((my-vector (vconcat l))) my-vector)) Only symbols, numbers, and lists. Any other macro could do something similar, so backquote is not just an exception, and was only an example that came to my mind first. If the definition of backquote would try to modify the read [,@l] vector, this vector of length 1, we would have a problem. But it only analyses this vector to produce some other code that doesn't even contain a vector any more. We must distinguish between the objects created when a program is read/compiled, i.e. the objects a program consists of (data and programs are the same in Lisp, etc.), and the objects that that program actually handles when it runs. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2020 03:24: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 To: Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873530273964 (code B ref 40671); Mon, 20 Apr 2020 03:24:02 +0000 Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 03:23:47 +0000 Received: from localhost ([127.0.0.1]:46361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQN2A-00011s-R6 for submit@debbugs.gnu.org; Sun, 19 Apr 2020 23:23:47 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQN28-00011c-9W for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 23:23:45 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 46ABA160065; Sun, 19 Apr 2020 20:23:38 -0700 (PDT) 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 Z51LtZUjVhd0; Sun, 19 Apr 2020 20:23:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 61DB3160079; Sun, 19 Apr 2020 20:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 sTgkaILQ5iUd; Sun, 19 Apr 2020 20:23:37 -0700 (PDT) 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 2A634160065; Sun, 19 Apr 2020 20:23:37 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sun, 19 Apr 2020 20:23:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87o8rnasfk.fsf@web.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/19/20 5:53 PM, Michael Heerdegen wrote: > Paul Eggert writes: > >>> (let ((l (list 1 2 3))) >>> `',l) >>> ==> '(1 2 3) >>> If you evaluate this (the return value is a valid expression), >>> `quote' >>> returns a list, but it's not a list literal. >> >> Sure, but one shouldn't be modifying that list. Once you hand a Lisp >> object to 'eval', modifying that object later ought to be a no-no even >> if the interpreter happens to do something non-crashy now. > > But I can modify the list before handing it over to `eval', > e.g. replacing the `1' with `cons'. Yes, that's fine. You can modify the list *before* handing it to eval, but it should be off limits afterwards. That is, the manual doesn't say or imply that the `,l yields a constant, so the result of the `,l is still modifiable. But once you hand the list off to eval, watch out: you shouldn't modify it. Another way to put it is: an object can start off mutable and later become constant when you start using it as part of a program. Come to think of it, perhaps this should be added to the Constants and Mutability section. Something like the following patch, perhaps. diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index abd258eb53..dd7eaf5ae4 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2400,6 +2400,11 @@ Constants and Mutability call @code{(make-string 3 ?a)} yields a mutable string that can be changed via later calls to @code{aset}. + A mutable object can become constant if it is passed to the +@code{eval} function, because you should not modify an object that is +being or might be executed. The reverse does not occur: constant +objects should stay constant. + Trying to modify a constant variable signals an error (@pxref{Constant Variables}). A program should not attempt to modify other types of constants because the > And even when I eval the original list, I get just the same l as before: It's OK that the interpreter does that. But you shouldn't *modify* the original list after handing it off to eval; it might work and it might not. You shouldn't even rely on the interpreter giving you the same l as before, for that matter; that's an implementation detail that is not documented and should not be documented, any more than we should document the fact that (let ((x (cos 1.5))) (eq x (+ x))) returns t in Emacs 27. > We must distinguish between the objects created when a program is > read/compiled, i.e. the objects a program consists of (data and programs > are the same in Lisp, etc.), and the objects that that program actually > handles when it runs. Yes, and the basic idea is that one cannot reliably modify the objects that a program consists of while running the program; it's not safe. (All we need to do is to word this correctly and clearly. :-) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2020 03:37: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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873537985159 (code B ref 40671); Mon, 20 Apr 2020 03:37:01 +0000 Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 03:36:38 +0000 Received: from localhost ([127.0.0.1]:46367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQNEc-0001L8-1c for submit@debbugs.gnu.org; Sun, 19 Apr 2020 23:36:38 -0400 Received: from mout.web.de ([212.227.17.11]:43935) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQNEa-0001Kv-EQ for 40671@debbugs.gnu.org; Sun, 19 Apr 2020 23:36:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1587353783; bh=hLKcO/FapN+d91jQ5J8IUed/5FitoMXA1PZcJTATa/Y=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=AmBCf1V8JkGcr4WC2Lcxa7gphOHZ9en+04dthAPKCMDd9BFce5uZ/h1n05E1eGS8a bp1FC3uCh/96c2qCzHa1i0IzplxaB4TIoGRHWc5lUiMBX+vjneuLu8cDxW6ku04AEm yJPJanSKZ9gMKU41gG9kUwIUsfdwVYbb4NMxHU6Q= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MY712-1jmSTX1J0i-00UnWk; Mon, 20 Apr 2020 05:36:23 +0200 From: Michael Heerdegen References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> Date: Mon, 20 Apr 2020 05:36:25 +0200 In-Reply-To: (Paul Eggert's message of "Sun, 19 Apr 2020 20:23:36 -0700") Message-ID: <877dyaltfq.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:LUk8vyD8giMaYCA7KhGqUW6lPosJGsrDe3V0B00m3+B7mFAsWVs ZzjsIn++9/kYa8fOB52lgCChhn4VVauVTgCtbv4sshEqvQHs6z+SDUMM1HArBawkwPIcVd+ /MSV2ZlKts+4H9M/LHJ3lhtBmBhuHV0mSOM3jmNsLDMa17zRIh2/AMxtx4OtcwUgR/+We5k M0an92CBNMVGHrjrxgmgw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:YYeXjuzs3v0=:xaRxqAW+w4EqkAhyOviDcI dDMaYVWJe+ncJIe6dYCSQysFscQLnxCD1IucTx3mOHIpvmglUBPZYr/u3M0o8NMijdDzLGPUB lY7DZcikWKUSeuEfup21wFEVbkKpP0nonqX3ZUGWic77YNJtW2qRgtsir6mwOkINQFmHFo4XF wUau/2vwnNHBU1oXpBP8iHVui1T82vkfstotYVVc9r88Z5q0wjNdYTRLBru4K86bLuNUCDhr+ 9EG+nbrfEl6Ycc3m/U2zkqZs4xSsfcXnfBC6zAAogT+rwTYqkJHcB3jfroVO/UZw0pdEdtcF9 FSGDt/c+TIfAsvHw8esIU61DzYJt2lbvTps1Z1+8p6eoT24UMuDshNTfG96/YkBTNQ/5A4wBv 7bG9/vY2MlPNf0HhYwm3RmpTK46h6lGlE96N4LL/Oi/m2AERSCpluD1/O7p3K8AFUVrrbLqqU gaPcYU0gzC55XWfxku5fTtVona0o2PhWydKocLiyJRaSrIfExSF97Crhk4r1oE0GCnu7O4MAX 7kkMbXLymGUU+LaI+obGZH7lLzqkHxHghsdq/AhX/8HeUITVAF2a48953DonPMnR25KjfcVSH oT8KxpT300r6sjKiDNT2UFK6RuUOoMltfEEHzvLhvRckNAvBD8qBvtpZUbBggoY1DLr9hvI4m gT9Q+CWEm/+wgItucISvK7Gz2VGyxpzBWCXma08+VCUoE5L5Y08H8PlVreLKWe6sLS3g05+Zu xxq9GB5T9X1aTBuLFAY9OGm9eEHjqN07bwgrZb+JbcPIcBTf6jR8miDBKB74zvj671qy2xkW6 suPDXk6sZBGhSA7a7+9mFahjNcHr93/1HA89R6/QcwFHEFFdXdhFL5RHBtRaM9GbRCq6xPRYr cWQwaiWA8tNEiA9cRQg45Ss0nMX3oBxljOaLkiFbGKDwym1Womn4ZmwTT7o3yGVh4kEhOeChi DYdm9khZZGpZuknBiXBlDJrNjR9Y27Rb377bAxbhCdq8/r2MyBACBEtXh5c6KKOU9n8Jsm750 o/kxJbT3k6CF/nZJs5aqnceT8CKBzBj346np9ozY7cMC7g+po9HJESvzjNKCC0oULdPamHBaj cuEbpf20PUDlqqfpFAhM3/wi1azM08dr4G70/sFX22Gyp6Ida4nbNsIN4IBMx3Tz9Mv8zqMBn y299Sz7KsgmCWPtdwe2+xA5+hzvJNLoyJv7uXeiiR7dEktUiQdfav8viS3dWO+gP+MVHTcCCf 4w4b7l4z+ImCjKg2l X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > + A mutable object can become constant if it is passed to the > +@code{eval} function, because you should not modify an object that is > +being or might be executed. The reverse does not occur: constant > +objects should stay constant. > + I don't know if what you say about the interpreter is true (I hope it is not), and I must really go to bed now, but "you should not modify an object that is being or might be executed" - isn't that quite common when calculating macro expansions (which, typically, are executed)? Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2020 05:33: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 To: Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158736077916059 (code B ref 40671); Mon, 20 Apr 2020 05:33:01 +0000 Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 05:32:59 +0000 Received: from localhost ([127.0.0.1]:46443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQP3C-0004Ax-S5 for submit@debbugs.gnu.org; Mon, 20 Apr 2020 01:32:59 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:47772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQP3B-0004Ak-3u for 40671@debbugs.gnu.org; Mon, 20 Apr 2020 01:32:57 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03K5TqUI144114; Mon, 20 Apr 2020 05:32:46 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=+a2HOSSmhoCTeZuodn09wubpUpB8lM+8eZfhYf/IiDw=; b=S4ZVWB1hGO4rUR5APk2IESdLfsIeXmvLbl7YJ3qKEnFlD/SqAV6/Rdy6UsDflcxO+Y/5 JfIhSF9GkWkQuMpZbj7YQqG060nXwHRQ6JFkIeFVOjRw2Ld6vwLzq71EvMc3xGrBGlSZ ZGL5QCN6afgEnbrkYgkCx3yO8JTw9D6TLE+lBMaFfBXxA3qmSqO9DjTva8Gy3jqaZwo9 ohfZXDcdLqFf7m27533w/IelvRWvLv3ZFl5nyrLqVjQhEBF8zn1ag0hPvzdFIkC56bhS alciZM1jowdx0eIqO26FqMdo4J8r+iFhuQmlPq4Lw7ddF/p9RGb1w+h9Wh7RQUUJOjRU VA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 30ft6mvwga-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Apr 2020 05:32:46 +0000 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 03K5RVpw029003; Mon, 20 Apr 2020 05:32:45 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 30gb3pqfxr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Apr 2020 05:32:45 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03K5WbB3011170; Mon, 20 Apr 2020 05:32:37 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 19 Apr 2020 22:32:36 -0700 (PDT) From: Drew Adams References: <87v9lzmdrw.fsf@laposte.net> <57532862-f6ec-84b6-13af-8a8985366ff0@cs.ucla.edu> <127084e8-c62a-ec8c-5d40-8c4280861519@cs.ucla.edu> <566aa1bf-444d-4cff-aed8-5b83fcd60107@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4966.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-2004200048 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 mlxlogscore=999 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004200048 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > Don't say "constant". Say "don't try to change it". >=20 > That's too long and awkward a phrase for use in lots > of places around the manual. We need a simple noun > phrase to describe the concept; this is Documentation 101. Giving it an undefined/unexplained name doesn't describe it at all. Giving it an existing name (e.g. "constant"), which means something else, indirectly describes it incorrectly. Why do we need to say this in "lots of places around the manual"? Explain the gotcha in one place, and if need to refer to that explanation elsewhere then do so (link).=20 > One possible substitute is "literal object", as Mattias > pointed out. Another possibility is "immutable object". > Perhaps others might be better. As I explained, none of those correspond to what I think the gotcha is. > > The only cases that are problematic are those where > > you can think your code modifies something (anew) > > when in fact it might not. >=20 > No, that's not the only issue. If you modify some of > these "constants" (or "literal objects" or whatever > term you like), the behavior is undefined: Emacs can > crash or remove your home directory or whatever. If Emacs can crash or remove your home directory, that's a bug, IMO. We don't document bugs, and we certainly shouldn't let Emacs crash and just tell you not to do XYZ because of that. Saying the behavior in some case is not defined means (usually) that we're not going to support/guarantee what the behavior is in that case, and we're not going to detail/say what it is. Saying some behavior is undefined is never (in my experience) done knowing it crashes the program. > There is no checking. If that's what's meant then say that. The explanation of the gotcha should, IMO, include a simple example of quoting a list: '(1 2 3), and then modifying some of that list structure. Say what can happen, e.g. with byte-compilation, and how that's different from what one might expect if '(1 2 3) is incorrectly thought of as always creating new list structure each time that code is evaluated. Maybe say that just reading the '(1 2 3) creates a list, and that thereafter that same list is used by the byte compiler. The point in showing a simple list example is to help make clear what's going on. More importantly, the quoted-list version of the gotcha is the common one. I don't want to belabor this. If you don't get what I'm saying then perhaps someone else will be willing to explain it better than I. Or if what I've said is unclear also to others, or is judged wrong, then please forget about it. To me, it's pretty simple in terms of effect: You write '(1 2 3), and you mistakenly think you've essentially written code that does what (list 1 2 3) does: creates a new list each time the code it's in gets evaluated. Maybe that '(1 2 3) code is in a context where it (looks like it) gets evaluated more than once. You think you're getting a new list (new conses) each time. Some other code modifies the list (e.g. using setcar). You think that code is modifying a new list each time, but it's not - it's modifying the same cons. Gotcha. There are no doubt other scenarios that exhibit essentially the same gotcha. But I don't think it's necessary to detail them all. What's needed is to provide the warning, some general description of the problem, and/or a simple example (using a list). From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2020 05:55: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 To: Paul Eggert , Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158736206018097 (code B ref 40671); Mon, 20 Apr 2020 05:55:02 +0000 Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 05:54:20 +0000 Received: from localhost ([127.0.0.1]:46471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQPNs-0004hp-Eb for submit@debbugs.gnu.org; Mon, 20 Apr 2020 01:54:20 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:37208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQPNr-0004hc-KF for 40671@debbugs.gnu.org; Mon, 20 Apr 2020 01:54:20 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03K5mWPn169356; Mon, 20 Apr 2020 05:54:10 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=n1y6FkW/2Bc6O2v6ITcKzUy3UCTTTS8PP90k7WLD7uw=; b=WDjc7pfpzYTRAY797wQYLsFo+LtUfVVoTHor+O3sqnsj12lLvLsSDuM0wr+W+fxzP9lQ aI+K/CW83nWHwgDdFX71OqwBWOszrJ1K4RVCIOpF57armYvD7K8etd40/idG4+9E3g54 RuQpie/nRu3ReLTarwG6bknNI/RrHHKsTEQmHOHs6CUy+xap5xbjyoXPpg+I7ymKMtBi Innzyy2MUwCIJzR1eCSkwHzE27/t/aUHWOeHVJo3fIAQiu9pcs2DpaOokZ8A932mYltH 0NWgM4N+8Y2YKN202UK1gFctrdNhe2W89PzxgkShDnSlJqL0JPw2xvPC5wWpQNWJcvhh Tg== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 30ft6mvym8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Apr 2020 05:54:10 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03K5qOvk193691; Mon, 20 Apr 2020 05:54:09 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 30gbb9evc4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Apr 2020 05:54:09 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03K5s207029321; Mon, 20 Apr 2020 05:54:02 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 19 Apr 2020 22:54:01 -0700 (PDT) From: Drew Adams References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4966.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004200051 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 mlxlogscore=999 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004200050 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Another way to put it is: an object can start off mutable and later > become constant I don't like that formulation at all. You must instead be talking about different objects. A mutable object cannot be changed to a constant, AFAIK. I think the gotcha we're talking about is thinking that a particular object is mutable when it's not. > +A mutable object can become constant if it is passed to the > +@code{eval} function,=20 How so? What's an example? > +because you should not modify an object that is > +being or might be executed. I don't think it even makes any sense to say that something can become something else _because you should not do XYZ_. That parses - is grammatical, but it makes no sense. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2020 06:03: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 To: Paul Eggert , Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158736257619264 (code B ref 40671); Mon, 20 Apr 2020 06:03:01 +0000 Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 06:02:56 +0000 Received: from localhost ([127.0.0.1]:46476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQPWC-00050d-Bg for submit@debbugs.gnu.org; Mon, 20 Apr 2020 02:02:56 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:44878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQPWA-00050P-HR for 40671@debbugs.gnu.org; Mon, 20 Apr 2020 02:02:55 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03K5wRPn189735; Mon, 20 Apr 2020 06:02:45 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=eOeAnApJI49H+8nA4kwfnGGEZPnsKaAlrVixCLEfp1E=; b=GireYKzbaAI0H8QfZP7DIofHWaEfugRBvtbqb+SEOkK7Q/W/bC8mltLYUy4QfbUuKfkk sd+QDDoNaw6ioxMX7P5kLkuxKZx+/ct05FEwdoP/qkBhY4BDuAnRfMlSjIds8G1zrRMy haDzlcDPGyVFP+DlAIRbxwTPL5a1Z+kHLwaX8+WGcaiCVNhHryvdjNWFKNgH3l8XAU77 eCdEB9n/+dK/RwuaKiaSIZOpb4mbZJl07vWJOKY8niqkPaWEN7rsGWt4Dp8sRpbgjzni QBwEnINCpYnS0lIukwsS9gbuVKN35vF/4DaDoJ+/XtbLuz5J4e9yVEtFbz9y9vIkZkje dw== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 30ft6mw0m7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Apr 2020 06:02:45 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03K5vLOa127550; Mon, 20 Apr 2020 06:02:44 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 30gb8vmh6u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Apr 2020 06:02:44 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03K62fcc001408; Mon, 20 Apr 2020 06:02:41 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 19 Apr 2020 23:02:40 -0700 (PDT) From: Drew Adams References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> In-Reply-To: <2225099d-16e1-645d-0342-a054da53363f@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)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=774 adultscore=0 bulkscore=0 suspectscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004200052 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9596 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 mlxlogscore=833 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004200052 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > the reason one shouldn't modify byte-code objects > is ... because doing so can make Emacs crash. Really? If something can make Emacs crash it means there's a bug; that's all. If there's a bug we shouldn't document the bugged behavior (it should be fixed), and we especially shouldn't, in the doc, say "you should [not] do XYZ" because it can make Emacs crash. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2020 14:11: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 To: Paul Eggert Cc: mattiase@acm.org, 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15873918298563 (code B ref 40671); Mon, 20 Apr 2020 14:11:01 +0000 Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 14:10:29 +0000 Received: from localhost ([127.0.0.1]:48152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQX80-0002E3-Ue for submit@debbugs.gnu.org; Mon, 20 Apr 2020 10:10:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40248 helo=eggs1p.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQX7y-0002Dn-6g for 40671@debbugs.gnu.org; Mon, 20 Apr 2020 10:10:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47863) by eggs1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQX7s-0004kk-D7; Mon, 20 Apr 2020 10:10:20 -0400 Received: from [176.228.60.248] (port=1321 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQX7r-0003TQ-4V; Mon, 20 Apr 2020 10:10:20 -0400 Date: Mon, 20 Apr 2020 17:10:15 +0300 Message-Id: <83368yi6yg.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <5c92a765-4502-3063-7f85-302cb1962caf@cs.ucla.edu> (message from Paul Eggert on Sun, 19 Apr 2020 13:45:07 -0700) References: <83tv1finob.fsf@gnu.org> <5c92a765-4502-3063-7f85-302cb1962caf@cs.ucla.edu> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Cc: mattiase@acm.org, 40671@debbugs.gnu.org, ke.vigouroux@laposte.net > From: Paul Eggert > Date: Sun, 19 Apr 2020 13:45:07 -0700 > > > For example, the node "Sets and Lists" now sometimes uses literal > > lists and sometimes non-literal ones -- without any explanation why. > > Likewise in "Association Lists" and "Sequence Functions". > > This was in response to your request to not change examples if the examples > didn't strictly need the changes. Although I preferred Mattias's original > proposal because it switched to the (list ...) style more uniformly, the patch I > installed mixed the '(...) and (list ...) styles because I thought that was what > you were asking for. > > I installed the attached patch, which attempts to address this issue by adding > comments that try to explain why (list ...) is needed sometimes. This is better, thanks. Although my feeling that we complicated what used to be a simple section is still here. > However, in > hindsight perhaps we should go back to the style used in Mattias's proposal, as > it's simpler and more consistent and doesn't distract the reader from the focus > of the documentation. Going back to Mattias's style would let us remove some of > the comments that the attached patch inserts. I think consistency should take a back seat in these situations. Clarity and easiness of reading and understanding are much more important. > As you note, it's not essential that the list be modifiable in this particular > example. That being said, the documentation should not suggest that it's OK to > use a destructive operation like delq on a constant, so further improvements > would be helpful here if someone can find the time. But that's exactly the disagreement between us: you think that each example must be perfect in that it follows all of the principles ever mentioned anywhere in the manual, and shouldn't go anywhere near the places which we explain elsewhere are, or might be, dangerous. The problem with that is that if you want to be absolutely correct and rigorous, you will more often than not be unable to say anything, or will produce code samples that are so arcane to the beginner that they will squarely miss their point. Witness your dialogue with Michael Heerdegen about related issues. I think there's no need to assign such crucial importance to every example. If it is easy to make the example more correct by small changes, we should consider doing that. But adding the likes of copy-list to an example that's supposed to show how to delete a list member is IMO a terrible overkill, and makes the example harder to understand: a reader who just learned about making and modifying lists suddenly needs to know what copy-list does (e.g., is it a deep copy or not?). IMO and IME, this kind of rigor is self-defeating, unless it comes in a special section marked "Advanced" or somesuch. Bottom line: IMO the manual should introduce the material gradually; it is okay to defer some subtle aspects to later sections, and initially simply disregard them. E.g., in a section that describes arithmetic operators like '+' in C to someone who is supposed to be a C beginner, you won't right away talk about integer overflow and the subsequent danger of crashing the system, and you won't tell the reader "don't ever use '+', use INT_ADD_WRAPV instead", nor will you replace examples that use '+' with that macro, would you? From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Apr 2020 01:26: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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158743234517424 (code B ref 40671); Tue, 21 Apr 2020 01:26:01 +0000 Received: (at 40671) by debbugs.gnu.org; 21 Apr 2020 01:25:45 +0000 Received: from localhost ([127.0.0.1]:48709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQhfU-0004Wx-Bd for submit@debbugs.gnu.org; Mon, 20 Apr 2020 21:25:45 -0400 Received: from mout.web.de ([212.227.15.3]:43023) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQhfS-0004Wk-O3 for 40671@debbugs.gnu.org; Mon, 20 Apr 2020 21:25:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1587432316; bh=mAbn2bY0QWzLTfpYFRrvkDGLUUrm7kmLGzp8AyGwHpU=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=fGsdorJcVfXFytk9wc/U/oOyPLfcbbdgFfEirHmWHR/Sj1Lc1Rj7KVAJAYfOL3d7r OP1abAUsjPMaRa1nDrPVYzUaxTdNfgkQewJAY+82d1RI/i+rC4UStoMGxkaYItoym+ UggcCM4AMrEzLLmBXSwhcdtmBc/srNdoMxaETIxY= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb002 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MRTzc-1jorH21j32-00SbHU; Tue, 21 Apr 2020 03:25:16 +0200 From: Michael Heerdegen References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> Date: Tue, 21 Apr 2020 03:25:17 +0200 In-Reply-To: <87a7376nv9.fsf@web.de> (Michael Heerdegen's message of "Mon, 20 Apr 2020 01:45:46 +0200") Message-ID: <877dy9wrya.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:z92rGYav6qkvHfI5uP++6+QKk1BJaiM8icbdlqCeoc4z1nT33IX YM6u5VPXJ6ZWDnJraYnWIE9RMaZR+29+212mtcVpt8JSlW4zsmuhm7y+O7m++zKVo4NlO79 lHIvbYCMSzGOBJH1cWa4rRNgwPwvH4zmwReTWxjR+Fv8Bzs1VF0lSGCmZVf1lavb+VMlHU2 mMoRCTnLULquxMr8kkifw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Bk/4zVHcS3E=:AiOAqKc+vNf6tlDamIo6MS w4WcYpwSWB8OvxBm6i3MoypGAzdRzPMyof0/u3f/eskR5YBLdR/nubpLNpiQC78vZg+pj4AYY 7pXyrJVNWDkQYoK/ewJreHNDK7fbdhiTTnTAp0I/rZ/FUkpuSOAHkDanhfArIzM2qn/LABaT9 YxokAG5XupiMfOMqkPAGR4Aa2iRAqpY04tEdUYdwQza7CSZOWVU4/tKKHb6Fzju8UQi80mFdk hV9TlLyn2V1fTTnEHyTj/J63vhule96aQfHBDqEG+6C6rIHMX4AFN/fUtZIrJ0Y+5xPvTFAVh N+PiYSMBGqCowg3zt+3CvgxXqIWETPmEZdQpi99xH2Eqw96P7zevgY6PpOP/ehTi8gC5ssegZ sc65K6lcSaekTTldH6s6Qt7w0wf/lNcxGTr1enwHLvsHMSt8559qRWUkSZigcZ3RKbxNBbHVH mPKAuukGKn6TCrbZm4aN6t90CscyEANaFvww4cFqMClHPuRwtPLWUunWhFJ78YnFhIq3su6t3 2NKc2v9zXb+h2D0G5+kQD2rZdwqaMmaie/42Am51bdeTdwd1whB/5iNLFEOdcUwtjHDQ2UqTS TH6A/oha1vgoZ427MFnzUqMrw0/J8Of8Ny5vPPXgGptCcT7KokUxmoqY8BwQvJrOSwbtX1Y2u jZiwyZg7ROJg6yz5wKqwzFmYsamd8o4v/EMXSCYguqinXO8dAeXTMIQmIrAKUuTo2IqS5p96g lLaD63zocNhqrjPxhLF6RNK2/uNVXqo1FxbD3FLfmFSKuJiI5GjpevqaIcqCifvWv1X8JZxe/ h4upx5DeCMBTSaolEeLhSfXeOyiwsxRCC9yj3KeYCxUmJYlGZONaEFoP8RX+X12qiAXquq8Fv 0TDv+kny2S310LQTlqDjna8U2m/fPb2Tpc/85cLBf0GmPjb7lm/h35DjX7ZC9e4Yvzrh8WEIP 0HW/ReRvU/ahKpmJAUCqprVfwiKkq/bZVsdpBpw2/wd2ZoEQC2Jo+b1Rwg6iQutZxITsCLSW4 QdQFUcKt4lNsVgO9ng4qHOdMnRt9gKAW2BK0MENzowq5C3dCXwBMtzU+MLEUBTOdwdNU7LTRn 3A+zCA27KrT9w8YwjQk5LPv3WDT5ye1T+jvbe37X5toY/KTpHHa0sBzO2QPQI3iy8Z16/L87K TUvFocQ9YfIW+t6jvqTveyu5yA25a0u6cHXner2w1q+aWPc/sY2Ked/ujqDtN+0+toZX18hUG fGSJQ7yGyG2cLBho/ X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Heerdegen writes: > > Yes, in hindsight I suppose you're right. If you like I can revert the > > changes now. > > I can't estimate, for me it is enough if you are willing to revert if > there is no consent and we discuss all of this now. But regardless of the impression that your chosen course of action gives (my own course of action often gives bad impressions for other reasons, and I don't mean to say that my impression is only bad, just a bit like...blindside?), it is harder now to review and estimate your changes in sum, and this is not good for the exchange of views that I think would be very valuable in this case. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Apr 2020 02:21: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 To: Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158743563522597 (code B ref 40671); Tue, 21 Apr 2020 02:21:02 +0000 Received: (at 40671) by debbugs.gnu.org; 21 Apr 2020 02:20:35 +0000 Received: from localhost ([127.0.0.1]:48748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQiWY-0005sP-QY for submit@debbugs.gnu.org; Mon, 20 Apr 2020 22:20:34 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQiWW-0005s9-SE for 40671@debbugs.gnu.org; Mon, 20 Apr 2020 22:20:33 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DB5951600C7; Mon, 20 Apr 2020 19:20:26 -0700 (PDT) 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 971yP0aVeDcL; Mon, 20 Apr 2020 19:20:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 38CFB160094; Mon, 20 Apr 2020 19:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 QL0ExI1nQZwJ; Mon, 20 Apr 2020 19:20:26 -0700 (PDT) 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 0733816008E; Mon, 20 Apr 2020 19:20:26 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <877dy9wrya.fsf@web.de> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Mon, 20 Apr 2020 19:20:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <877dy9wrya.fsf@web.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/20/20 6:25 PM, Michael Heerdegen wrote: > it is harder now to review and estimate your changes > in sum Yes, software archaeology can be a bit of a pain. You could try running this shell command: git diff eebfb72c906755c0a80d92c11deee7ac9faf5f4b^..05089a4d65831c5e873956f5f2d92a3d5672d405 -- doc/lispintro doc/lispref/elisp.texi doc/lispref/eval.texi doc/lispref/keymaps.texi doc/lispref/lists.texi doc/lispref/objects.texi doc/lispref/sequences.texi doc/lispref/strings.texi though if the doc evolves further the command could get longer.... From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 06:31: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 To: Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15875370528327 (code B ref 40671); Wed, 22 Apr 2020 06:31:02 +0000 Received: (at 40671) by debbugs.gnu.org; 22 Apr 2020 06:30:52 +0000 Received: from localhost ([127.0.0.1]:51132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jR8uK-0002AF-2e for submit@debbugs.gnu.org; Wed, 22 Apr 2020 02:30:52 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jR8uH-00029z-SC for 40671@debbugs.gnu.org; Wed, 22 Apr 2020 02:30:51 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6F31B160052; Tue, 21 Apr 2020 23:30:43 -0700 (PDT) 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 eqFUtllZmKoE; Tue, 21 Apr 2020 23:30:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9103E1600AF; Tue, 21 Apr 2020 23:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 O-fBMgbmgCrr; Tue, 21 Apr 2020 23:30:42 -0700 (PDT) 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 623BD160052; Tue, 21 Apr 2020 23:30:42 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <877dyaltfq.fsf@web.de> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <60f0eb0d-7761-6167-c6c5-42b1a1267152@cs.ucla.edu> Date: Tue, 21 Apr 2020 23:30:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <877dyaltfq.fsf@web.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/19/20 8:36 PM, Michael Heerdegen wrote: > Paul Eggert writes: > >> + A mutable object can become constant if it is passed to the >> +@code{eval} function, because you should not modify an object that is >> +being or might be executed. The reverse does not occur: constant >> +objects should stay constant. >> + > > I don't know if what you say about the interpreter is true (I hope it is > not), Unfortunately it is true, for performance reasons: you can't reliably change a form that is currently being executed by the Lisp interpreter. This is because the interpreter can cache parts of such forms, or can check forms and later execute them under the assumption that the checks succeeded, and if the caches are invalid or the earlier checks no longer apply then Emacs can dump core or worse. > "you should not modify an > object that is being or might be executed" - isn't that quite common > when calculating macro expansions (which, typically, are executed)? You can modify the object before giving it to 'eval' (and macro expansion can do modifications like that), but you shouldn't modify it while it's being evaluated. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 17:22: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 To: Drew Adams , Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15875761212238 (code B ref 40671); Wed, 22 Apr 2020 17:22:02 +0000 Received: (at 40671) by debbugs.gnu.org; 22 Apr 2020 17:22:01 +0000 Received: from localhost ([127.0.0.1]:53111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJ4S-0000a2-Pd for submit@debbugs.gnu.org; Wed, 22 Apr 2020 13:22:00 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJ4R-0000Zo-0g for 40671@debbugs.gnu.org; Wed, 22 Apr 2020 13:21:59 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F3B54160017; Wed, 22 Apr 2020 10:21:52 -0700 (PDT) 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 oI47bhpAbL2W; Wed, 22 Apr 2020 10:21:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 46DBD160094; Wed, 22 Apr 2020 10:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 aZT-D_4auKgp; Wed, 22 Apr 2020 10:21:52 -0700 (PDT) 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 0B42B160017; Wed, 22 Apr 2020 10:21:52 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> Date: Wed, 22 Apr 2020 10:21:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/19/20 10:54 PM, Drew Adams wrote: > A mutable object cannot be changed to a constant Sure they can. This idea is common in other languages, e.g., see Object.freeze method in JavaScript. There's no reason Emacs Lisp can't use the idea. >> +A mutable object can become constant if it is passed to the >> +@code{eval} function, > > How so? What's an example? (let ((x (make-string 1 ?a))) (eval `(progn (defun foo () (let ((a ,x)) (aset x 0 ?b) (list a "a" (equal a "a")))) (byte-compile 'foo) (foo)))) This code is not well-formed because it modifies the string x after passing it to eval (such strings should be constant). As a result, the behavior of the program is unpredictable. On master it currently yields ("b" "b" t) but there's no guarantee of this. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 17:37: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 To: Drew Adams , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15875769863657 (code B ref 40671); Wed, 22 Apr 2020 17:37:01 +0000 Received: (at 40671) by debbugs.gnu.org; 22 Apr 2020 17:36:26 +0000 Received: from localhost ([127.0.0.1]:53133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJIQ-0000wv-Iv for submit@debbugs.gnu.org; Wed, 22 Apr 2020 13:36:26 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:46798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJIO-0000wZ-Hx for 40671@debbugs.gnu.org; Wed, 22 Apr 2020 13:36:25 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1B1B9160017; Wed, 22 Apr 2020 10:36:18 -0700 (PDT) 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 N-9-5kBXwIm3; Wed, 22 Apr 2020 10:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4C73B1600CD; Wed, 22 Apr 2020 10:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 fLiZDHOqPOB3; Wed, 22 Apr 2020 10:36:17 -0700 (PDT) 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 13465160017; Wed, 22 Apr 2020 10:36:17 -0700 (PDT) References: <87v9lzmdrw.fsf@laposte.net> <57532862-f6ec-84b6-13af-8a8985366ff0@cs.ucla.edu> <127084e8-c62a-ec8c-5d40-8c4280861519@cs.ucla.edu> <566aa1bf-444d-4cff-aed8-5b83fcd60107@default> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <5d62a8ef-a8c2-9b37-5d50-41035cedc4c1@cs.ucla.edu> Date: Wed, 22 Apr 2020 10:36:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/19/20 10:32 PM, Drew Adams wrote: > Giving it an existing name (e.g. "constant"), which means > something else In informal language the word "constant" can mean different things to different people. If the manual defines the word "constant" to mean "an object whose value should never change" and it uses that word consistently, then that's OK; the manual's terminology corresponds closely enough to the informal one. Of course if we can come up with a better phrase than "constant" then we should use that; but so far we haven't seemed to be able to. > Explain the gotcha in one place, and if > need to refer to that explanation elsewhere then do so > (link). Yes, that's what's done now. > If Emacs can crash or remove your home directory, > that's a bug, IMO. We don't document bugs We should advise Lisp programmers about what they can do safely, and what they should not do due to Emacs's unfortunate limitations. We already do this in other dangerous areas (e.g., what happens if you increase max-lisp-eval-depth too far), and we should do it in this dangerous area too. You're right that we needn't document in detail what happens if a Lisp program does unsafe things. > we certainly shouldn't let Emacs crash If we can fix the problem that would be better, yes. However, it's not practical to do that for Emacs 27 because it is so close to release and any fix would require major surgery. It's not clear that it's practical to fix things even for Emacs 28. > Saying some behavior > is undefined is never (in my experience) done knowing > it crashes the program. Welcome to the wonderful world of undefined behavior. I'm joking of course; undefined behavior is not a good thing. But here we are. > Maybe say that just reading the '(1 2 3) creates a > list, and that thereafter that same list is used by > the byte compiler. Thanks, I'll add something along those lines. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Apr 2020 00:51: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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Drew Adams , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158760300121710 (code B ref 40671); Thu, 23 Apr 2020 00:51:02 +0000 Received: (at 40671) by debbugs.gnu.org; 23 Apr 2020 00:50:01 +0000 Received: from localhost ([127.0.0.1]:53643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRQ41-0005dz-B0 for submit@debbugs.gnu.org; Wed, 22 Apr 2020 20:50:01 -0400 Received: from mout.web.de ([212.227.15.14]:39879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRQ3y-0005dk-SQ for 40671@debbugs.gnu.org; Wed, 22 Apr 2020 20:49:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1587602970; bh=/kuEyfdVr3zPu4IWLS/q0il/jz+UWAhtUMU/bn5gfHA=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=TFOow9cLn4Y78/e6RwazPjqw0IsNw4xS0VwZ/RVx8EHjIK+AYzEf2M8vJ4KQ2383Y /Br3NBuB2xiyMyeQH5LofcaSmtD77SuTytjmwynAQSrTDQJVFkA37gfhSay58o4Mag 8SJQ+HxzGGQYsSuG/mET3YTKo2JY9dbWPKmK44TI= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb002 [213.165.67.108]) with ESMTPSA (Nemesis) id 0LtXDY-1j1sQn3dky-010qgz; Thu, 23 Apr 2020 02:49:30 +0200 From: Michael Heerdegen References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> Date: Thu, 23 Apr 2020 02:49:30 +0200 In-Reply-To: <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> (Paul Eggert's message of "Wed, 22 Apr 2020 10:21:51 -0700") Message-ID: <871rofxbz9.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:85XZt36pLKj+CLSDQAVC21MeMTjuLl2rlSgnHlIMU9YpDgYbrzu +UtINO3zKlcDrNTsO2ojeFEjHsXJRn6j7RhVibrmROy8mPTNQNtRPUfU6E2tXgURlTNEELo k9zU9IBB7lEHEmoS1HbYLFNvT6I9yz3SnoDAdRJqyBl5WSfkBBpnjdqm8vokL6yKuLVHf48 Xk3MAmJUqDOEgPU80y0nA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:uRImqVldqmM=:YLcD4uLIG2TCC8zMoXozi8 0v4d/45E6ney3A10IQtomlSr6HMiPyJiqM06KMswAhOlkIvfabK7HWmChJy8GgTzioCs3w2hI WlDpveNW6rRbo8vPYWhrqDJ37mdUGI2ot5pLZ6wkDQGRc6d1TKCoC/kPED8odS2SG6KVWk2Yk WdZVUbhSkf1yfzrAVXvD8qYbl4xjHcWudoDnNcf09nKrQ4PeVoJrhLuTbnauZBWtNaPzduWHz 6N5FWB8dpk8c3coffMA577YHkQACtKGIzpMzestcJIA095/8b1X76GJ7iMrWb5dvQPGwl4OnV OGcknOgv8hXEKXXVvWBaZPgLj4tJ76L4mWJiA8n8E8EiqsuuFSRQ2Ue+FKvAB6a/fADejSsdz d/OnK521TdPNUu4EHvT/uM9npG8Xmrwz2jGhVxkTDngJwp9K3XpibppGL7xmIbPrgn2uHneiS qwrioRrKj6yzUbP6wrZa+4rGs8QYAu83JLJULybMIfw7VXK0mFvLBZ1IOEHJAZgFqwnps4xH2 +29Lt4dAetsb+99V50rPJCR6BluoaKfI4DboLyKhiwy8cSERqEy0DRqpMcgY2gwbzfDWukoaQ Jem/iqqi/2+X3CgKKuSKPYSEGYtdhX2kpKsu0n4EPP1mQZ+ifIZtjIozChe78MUp+wIYd+HBo Uwd5B03pBS0aDDMF9TblwVxToPiT0dunALmTdXbywEV+ol0IKqCNUdA/kVo54ofZ9BrWU+1qp Rg4SAFInoEMNvC1cwVmhkMXjJi3spyBWYXfnX5uID/bO5T5UeN+HMI3h5ZXrLnQvvQVoERTaF aRvGXHhsIU+ev34vrDYi8zCopz/DtoJwsrMoeCyIab+fcR0rkGcIrgDaYikGjm5N96Nzw4k+j Bh3FAegxb/LAePabjX0yw/u+NJlAnwdbVheeJnMYpGYC/yuxw4PmeJpIagSs2Q5S0qAb+o4qN 7Ubv7WYcZ9wSFbrUNw9yFnoaN1DzgB6DpIkTTzKemkTG2lpPWuQIFMzZlbyu65jlM11QDzxnw 5h5qndh3QFdiJ/09BbNtO9xs73jHRPIIl0kmzRgOI3tpRBX8pbPO6saClIxE/OCRaxup5+jWR /wGTwxj7lV4QPFZbijKTx8jxSADXhqHt2/VXCHASTQuoB/4m2szxqbPsD5jvVXUmCzxy/MwMx 3Ay0CArmP8lczT5d2EueJUH1qT4buBihEd2qVPDKQOWQk8CtH+ToWvSWP2ilNSwGe2fQ1xmMI HvOch9TFFnaZYJCm1 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > > A mutable object cannot be changed to a constant > > Sure they can. This idea is common in other languages, e.g., see > Object.freeze method in JavaScript. There's no reason Emacs Lisp can't > use the idea. Ok. I still have questions and objections about your additions: + A mutable object can become constant if it is passed to the +@code{eval} function, because you should not modify an object that is +being or might be executed. The reverse does not occur: constant +objects should stay constant. `eval' is used quite rarely. Can what you describe happen under other circumstances, or does it only happen to `eval'? E.g. what about this case for example: (let ((l (list 1 2 3))) (funcall (lambda () l))) Has the list become a constant? I ask because the sub-clause "because you should not modify an object that is being or might be executed" is totally different statement than that about `eval'. A list literal (1 2 3) or a string as in the example in your answer to Drew are surely not executed, as they are not valid forms. They are part of a program. But anything a macro generates also becomes part of a program. Maybe I misread "might be executed" as "might be executed in the future" and you actually meant something like "might (currently) be executed (as part of the expression the interpreter currently executes). BTW, speaking about Lisp the term "evaluate" is probably preferable to "execute" I think. Thanks, Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Apr 2020 02:38: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 To: Michael Heerdegen Cc: mattiase@acm.org, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Reply-To: rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.1587695823726 (code B ref 40671); Fri, 24 Apr 2020 02:38:02 +0000 Received: (at 40671) by debbugs.gnu.org; 24 Apr 2020 02:37:03 +0000 Received: from localhost ([127.0.0.1]:56127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRoD9-0000Be-Gg for submit@debbugs.gnu.org; Thu, 23 Apr 2020 22:37:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43048) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRoD8-0000B6-FG for 40671@debbugs.gnu.org; Thu, 23 Apr 2020 22:37:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33352) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRoD2-0002gu-1n; Thu, 23 Apr 2020 22:36:56 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jRoD1-0006ib-5R; Thu, 23 Apr 2020 22:36:55 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: <871rofxbz9.fsf@web.de> (message from Michael Heerdegen on Thu, 23 Apr 2020 02:49:30 +0200) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> Message-Id: Date: Thu, 23 Apr 2020 22:36:55 -0400 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] It seems strange to use the terms "constant" and "mutable" to describe whether modifying its contents is something you had better avoid. I think people will find that terminology confusing. Normally "mutable" means that you CAN change it, not that it is OK to change it. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Apr 2020 15:09: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 To: rms@gnu.org, Michael Heerdegen Cc: mattiase@acm.org, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158774092720598 (code B ref 40671); Fri, 24 Apr 2020 15:09:02 +0000 Received: (at 40671) by debbugs.gnu.org; 24 Apr 2020 15:08:47 +0000 Received: from localhost ([127.0.0.1]:57730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRzwd-0005M9-7Y for submit@debbugs.gnu.org; Fri, 24 Apr 2020 11:08:47 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:43344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRzwb-0005Lw-Kj for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 11:08:46 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03OEqfeC011814; Fri, 24 Apr 2020 15:08:28 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=252WgDjABdorGVIZZLOuacs0CLeDxLYWwyePmjMN+R8=; b=bhcTapn+1Vs5eLVNDFKEMFDvzaYy6/QVjR2QGbX6rD1K+gFvCRf9hnpAoQs07Kipnplk CKH1H65hKPay+hMWnxmqBLgnScEGVEAKyrCgC5qVYwW8k67+cjqXWf6yJV6Q5sbmxx6N /siOpy0/qH4IJZnbis9GDLCr9EcemQRp/pozX6ZSNkmWfH5hVWK0aWWpDCAmC8km/h+8 dyFYCKopZsS9gR7S3wRq+mDBzJM0fPw7x8BcDh12E2MzUaOmuKbvsRsykasD3OFee0xw g4sIiohWM+2l1F+8Pt0w9wxGvHRQrm1N1d/3NhtJsPcjTfLlmIUEYn0oqSzGx44gflz/ Hw== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 30ketdmvf6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Apr 2020 15:08:28 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03OF7lCR072649; Fri, 24 Apr 2020 15:08:28 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 30k7qxac05-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Apr 2020 15:08:28 +0000 Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03OF8KAQ002534; Fri, 24 Apr 2020 15:08:20 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 24 Apr 2020 08:08:19 -0700 (PDT) From: Drew Adams References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9601 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 mlxlogscore=985 adultscore=0 suspectscore=0 bulkscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004240120 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9601 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 spamscore=0 impostorscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 priorityscore=1501 clxscore=1015 suspectscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004240120 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > It seems strange to use the terms "constant" and "mutable" to describe > whether modifying its contents is something you had better avoid. > I think people will find that terminology confusing. Normally > "mutable" means that you CAN change it, not that it is OK to change it. Yes. Precisely what I, Michael, and others said. The message should be one of advice/guidance: explaining a gotcha, or at least suggesting what to avoid. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Apr 2020 16:40: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 To: Richard Stallman Cc: Michael Heerdegen , ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158774639429150 (code B ref 40671); Fri, 24 Apr 2020 16:40:02 +0000 Received: (at 40671) by debbugs.gnu.org; 24 Apr 2020 16:39:54 +0000 Received: from localhost ([127.0.0.1]:57837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jS1Mo-0007a6-Bn for submit@debbugs.gnu.org; Fri, 24 Apr 2020 12:39:54 -0400 Received: from mail1465c50.megamailservers.eu ([91.136.14.65]:35114 helo=mail268c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jS1Ml-0007Zp-R9 for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 12:39:53 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1587746373; bh=WiOXY+XarX7wQ62iKxR98YDnCrSTW2fgFGSDd8iyCMM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=nTNe9VtkNSYEuWnp/V7x8jMAIkhOepYI7Oe48kzbrL/s8rLRQVyivpYkutTWVsa5/ NStw1i0vHgHeVP6po1jp9X4uzhWJV8NhkBxdTDSlyPldDAwcDBTPREbeq8cLvbkkWP VpV7dL4PopsDuhnAocu4bAOaSs+ReblRuttdFWgU= Feedback-ID: mattiase@acm.or Received: from stanniol.lan (c-4e4ae655.032-75-73746f71.bbcust.telenor.se [85.230.74.78]) (authenticated bits=0) by mail268c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 03OGdUsW026397; Fri, 24 Apr 2020 16:39:31 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: Date: Fri, 24 Apr 2020 18:39:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> X-Mailer: Apple Mail (2.3445.104.14) X-CTCH-RefID: str=0001.0A782F19.5EA31645.005B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=BZ+mLYl2 c=1 sm=1 tr=0 a=klNLuyVZdLUgl+K5Uafb2A==:117 a=klNLuyVZdLUgl+K5Uafb2A==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8 a=GuW4MMiu9jjuFNPyENIA:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 24 apr. 2020 kl. 04.36 skrev Richard Stallman : > It seems strange to use the terms "constant" and "mutable" to describe > whether modifying its contents is something you had better avoid. > I think people will find that terminology confusing. Norm [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: gnu.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 24 apr. 2020 kl. 04.36 skrev Richard Stallman : > It seems strange to use the terms "constant" and "mutable" to describe > whether modifying its contents is something you had better avoid. > I think people will find that terminology confusing. Normally > "mutable" means that you CAN change it, not that it is OK to change = it. That is an interesting point. What is the difference between CANNOT and = SHOULD NOT, operationally? To the user, nothing; there is no gain from = disobeying our advice. Implementation-wise, it's whether there are = strong checks or not. (For example, in C you should not read from = already freed memory, but there is no mechanism actually preventing you = from doing so.) It's useful to have the option to add strong checks, so that (setcar '(1 = . 2) 3) throws an error. Then, what used to be SHOULD NOT turns into = CANNOT, but the attentive user has no reason to change behaviour. Of course the real world is messy and people sometimes have code that = breaks the rules but still seem to work. There would need to be a = transition period, and a switch to run in a permissive mode. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Apr 2020 16:47: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 To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Richard Stallman Cc: Michael Heerdegen , ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158774680929813 (code B ref 40671); Fri, 24 Apr 2020 16:47:02 +0000 Received: (at 40671) by debbugs.gnu.org; 24 Apr 2020 16:46:49 +0000 Received: from localhost ([127.0.0.1]:57845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jS1TV-0007kn-CT for submit@debbugs.gnu.org; Fri, 24 Apr 2020 12:46:49 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:33817) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jS1TT-0007ka-Sp for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 12:46:48 -0400 Received: by mail-wr1-f46.google.com with SMTP id j1so11700613wrt.1 for <40671@debbugs.gnu.org>; Fri, 24 Apr 2020 09:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QKyUc7ZEs44MmYiN00izD7j6G7DRop52lxBuO2ET5dg=; b=ND9/XII2qWaGNLfgXzA08YnHgVSAh1lnA9YStMa4BSq2B55QQN+oAQkyF83fP3FiAf h5VvDDvW1YDzQbBS8GSQ0JozOeSXNsg4E7/9lvcKqNYtx81YLAmYMo5s9RCt/U4LYjrs O07yvhXTORfKOS39PnJuY62+kHnQoklWPRdHfBSFjTqgu51BNt8moGpZSZUgRbCqfZ4Q 2Dwdf92q422KJZsXKSoehAdzZsdPsVj4qLpMKU6SCjemYhvh232K7yQgNa9+JbASlzJN sTsSjEpO4WZxCAwhdN7eE5B8kMXwl+QP6aicS1GU/i0SM70x5+GoLP2nAaHYsmX1cCTG IZIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QKyUc7ZEs44MmYiN00izD7j6G7DRop52lxBuO2ET5dg=; b=LIL0Hw2t/kIejj+GT/IGpX88zvCIvbGi9dkcLr5f6jR48M66tayfuPkCWd/9p0v8Tm 2x3f0PEqOXPYK3A1Cwo6ZP9kQQ4mQmvLgODegMcySLDGuPEZZvGcct9owgLovrTTtlUc iSHGl1MqFpGuX38CzTsP8dB9pRprU3AobpT+hhU4LREDRHLcmqfS0tKp96I7Alc1heLF TgnPRN+oe7QFUY9FHGMFqnCIKJvWObRyyxbMueN4iJxsi4obu/xmacO/X0MwI0ADiblc kqvKodIBAT1sEjqXyH927BP15daAgD7NE1q0DhO0m7gP+FApM9GIz9vKZXoSBOnpxKdQ fOSQ== X-Gm-Message-State: AGi0Pua7zbRsrk/01M8jPg3cyiQY2x69znS0diZ2CATTTUvXn/wHeicl PACiQKEFsBU6Xv1jaiLyH1gtVeEimaE= X-Google-Smtp-Source: APiQypLthDvAMJHqm9DdCBIv/BQs4Y3yWNCfMnkjeEJchSz6Mhv+xOoC0NKGYD23dWtzU0UjSmqdmg== X-Received: by 2002:a5d:4301:: with SMTP id h1mr12477745wrq.144.1587746801758; Fri, 24 Apr 2020 09:46:41 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id i129sm3781799wmi.20.2020.04.24.09.46.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Apr 2020 09:46:41 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> From: Dmitry Gutov Message-ID: <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> Date: Fri, 24 Apr 2020 19:46:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 24.04.2020 19:39, Mattias Engdegård wrote: > That is an interesting point. What is the difference between CANNOT and SHOULD NOT, operationally? To the user, nothing; there is no gain from disobeying our advice. The difference is at runtime, obviously. And the problem is using the words in a way that differs from other programming languages, for instance. > It's useful to have the option to add strong checks, so that (setcar '(1 . 2) 3) throws an error. Then, what used to be SHOULD NOT turns into CANNOT, but the attentive user has no reason to change behaviour. *If* we do that, we could call them constants. But I imagine we never will, for backward compatibility reasons. Emacs core itself modifies these "constants" at runtime in quite a few places, I'm sure. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Apr 2020 17:21: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 To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Richard Stallman Cc: Michael Heerdegen , ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.1587748859319 (code B ref 40671); Fri, 24 Apr 2020 17:21:01 +0000 Received: (at 40671) by debbugs.gnu.org; 24 Apr 2020 17:20:59 +0000 Received: from localhost ([127.0.0.1]:57861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jS20Y-000054-P1 for submit@debbugs.gnu.org; Fri, 24 Apr 2020 13:20:59 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:52842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jS20W-0008WT-5q for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 13:20:56 -0400 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 03OHIwv6127197; Fri, 24 Apr 2020 17:20:39 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=mhoaTni7AU+JXzR4ODp4SknLno0m5bgcVL4lc0ePhcU=; b=LSfNAEspxf8fgS5GS46yKviyvlt6nVURCtZdLwy2F9QuNunryn/HuHXyJepy9NWoSVAL dzn172dRUvaPRyw/aSkKcQYMcG0Okwir3WZ1TiUnhQd6ObG9O99FWLKJYdwvQpgaE9xU NqmrI7iQSc4klMn94ZLjvJNin+0Z0prSRg90SWgBMCJ6g2UZPuqH5Zs805dz42sWJ3UG /UoeknOPRLtQLZaZgieMDJgT/IGeqAwOBHm6Q3X/IDx1Zk8GfdcrTDgYoQkB3T+16lt7 LP5B/7fBMosmjAkD+Mc6IaQ5lOw3zgkT/Q3tv1xPs1b+5FcVMzWDftBFYwGNWNDDRxeF vw== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 30jvq52a7p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Apr 2020 17:20:39 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03OH7mSl127118; Fri, 24 Apr 2020 17:18:38 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 30k7qxh5ec-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Apr 2020 17:18:38 +0000 Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03OHIYgQ000950; Fri, 24 Apr 2020 17:18:34 GMT MIME-Version: 1.0 Message-ID: <68ef2c1e-0b60-4a9d-b781-4dabf71a6e7f@default> Date: Fri, 24 Apr 2020 10:18:33 -0700 (PDT) From: Drew Adams References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9601 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 bulkscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004240133 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9601 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 adultscore=0 mlxlogscore=999 phishscore=0 impostorscore=0 clxscore=1015 bulkscore=0 spamscore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004240133 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > It seems strange to use the terms "constant" and "mutable" to > > describe whether modifying its contents is something you had > > better avoid. I think people will find that terminology > > confusing. Normally "mutable" means that you CAN change it, > > not that it is OK to change it. >=20 > What is the difference between CANNOT and > SHOULD NOT, operationally? To the user, nothing; there is no gain from > disobeying our advice. No. To the user: something. And the negative effects might not be immediately noticeable. If we say that you can't modify XYZ there's no need for you to pay attention, learn about the gotcha, and try to avoid modifying XYZ. The burden here is on the user (unfortunately). Emacs Lisp doesn't protect you from doing what you'd be told you "cannot" do. It's up to you to know when you might be stumbling onto this pitfall and avoid it. Telling users they _can't_ fall into this pit is like telling someone it's impossible for their car to go through a red light. Nope, they're the driver, and the message should be, "Don't drive through a red light." From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 01:59: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 To: Drew Adams , rms@gnu.org, Michael Heerdegen Cc: mattiase@acm.org, 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158777993731871 (code B ref 40671); Sat, 25 Apr 2020 01:59:01 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 01:58:57 +0000 Received: from localhost ([127.0.0.1]:58289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSA5o-0008Hz-Mr for submit@debbugs.gnu.org; Fri, 24 Apr 2020 21:58:56 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSA5n-0008Hl-3j for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 21:58:55 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0315816008D; Fri, 24 Apr 2020 18:58:49 -0700 (PDT) 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 RnBQE7wDojzM; Fri, 24 Apr 2020 18:58:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 54D4B1600D3; Fri, 24 Apr 2020 18:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 tWrGsyRD9Vet; Fri, 24 Apr 2020 18:58:48 -0700 (PDT) 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 18AE816008D; Fri, 24 Apr 2020 18:58:48 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <95e3ee3f-4eaf-f510-a840-c3783d2bf6c5@cs.ucla.edu> Date: Fri, 24 Apr 2020 18:58:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/24/20 8:08 AM, Drew Adams wrote: > The message should be one of advice/guidance: > explaining a gotcha, or at least suggesting what > to avoid. That's what the current emacs-27 manual does, or tries to do. If it doesn't do so clearly enough, specific suggestions for improving the wording would be helpful. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 02:22: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 To: Dmitry Gutov , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Richard Stallman Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15877812861478 (code B ref 40671); Sat, 25 Apr 2020 02:22:02 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 02:21:26 +0000 Received: from localhost ([127.0.0.1]:58294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSARZ-0000Nl-HI for submit@debbugs.gnu.org; Fri, 24 Apr 2020 22:21:26 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:57060) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSARY-0000Na-4M for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 22:21:24 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A325916008D; Fri, 24 Apr 2020 19:21:18 -0700 (PDT) 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 zWg7wEqK6m4K; Fri, 24 Apr 2020 19:21:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D9B5A1600D3; Fri, 24 Apr 2020 19:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 5lcDSNEo_4IK; Fri, 24 Apr 2020 19:21:17 -0700 (PDT) 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 720B816008D; Fri, 24 Apr 2020 19:21:17 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> Date: Fri, 24 Apr 2020 19:21:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/24/20 9:46 AM, Dmitry Gutov wrote: > On 24.04.2020 19:39, Mattias Engdeg=C3=A5rd wrote: >> That is an interesting point. What is the difference between CANNOT an= d SHOULD >> NOT, operationally? To the user, nothing; there is no gain from disobe= ying our >> advice. >=20 > The difference is at runtime, obviously. And the problem is using the w= ords in a > way that differs from other programming languages, for instance. That depends on what other programming languages we're talking about. The current use of 'constant' in the manual corresponds reasonably closely to 'const' objects in C and C++. >> It's useful to have the option to add strong checks, so that (setcar '= (1 . 2) >> 3) throws an error. Then, what used to be SHOULD NOT turns into CANNOT= , but >> the attentive user has no reason to change behaviour. >=20 > *If* we do that, we could call them constants. But I imagine we never w= ill, for > backward compatibility reasons. Emacs core itself modifies these "const= ants" at > runtime in quite a few places, I'm sure. Actually Emacs formerly was more careful about this sort of thing: more o= bjects were constant and Emacs reliably signaled an error if you tried to change= them. If we brought back this feature we'd actually be more backwards-compatibl= e than we already are, at least in some sense. I expect it'd be a good thing to = do if it didn't hurt performance, as it should help reliability/safety a bit. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 02:23: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 To: Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Drew Adams , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15877813501581 (code B ref 40671); Sat, 25 Apr 2020 02:23:02 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 02:22:30 +0000 Received: from localhost ([127.0.0.1]:58298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSASc-0000PR-ID for submit@debbugs.gnu.org; Fri, 24 Apr 2020 22:22:30 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:57180) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSASb-0000PD-4B for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 22:22:29 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C797F16008D; Fri, 24 Apr 2020 19:22:23 -0700 (PDT) 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 VIS62eHtc7LI; Fri, 24 Apr 2020 19:22:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DEAE41600D3; Fri, 24 Apr 2020 19:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 y81sw5eb2WO6; Fri, 24 Apr 2020 19:22:22 -0700 (PDT) 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 A6F2616008D; Fri, 24 Apr 2020 19:22:22 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Fri, 24 Apr 2020 19:22:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <871rofxbz9.fsf@web.de> Content-Type: multipart/mixed; boundary="------------6E97AB9219D2496F0B390A35" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------6E97AB9219D2496F0B390A35 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/22/20 5:49 PM, Michael Heerdegen wrote: > + A mutable object can become constant if it is passed to the > +@code{eval} function, because you should not modify an object that is > +being or might be executed. The reverse does not occur: constant > +objects should stay constant. > > `eval' is used quite rarely. Can what you describe happen under other > circumstances, or does it only happen to `eval'? E.g. what about this > case for example: > > (let ((l (list 1 2 3))) > (funcall (lambda () l))) > > Has the list become a constant? No, because the list is not part of the expression that is being evaluated. However, something like this could cause trouble: (let ((l (list 'lambda '(x) '(setcdr l x)))) (eval (list l l))) because it modifies the list l while it is evaluating it. (As it happens, this code behaves differently in Emacs 26 than it does in Emacs 27 - that's what you can get with undefined behavior....) > Maybe I misread "might be executed" as > "might be executed in the future" and you actually meant something like > "might (currently) be executed (as part of the expression the > interpreter currently executes). > > BTW, speaking about Lisp the term "evaluate" is probably preferable to > "execute" I think. Both good points. The word "executed" is already gone from the manual, and I installed the attached patch to try to address the other point. --------------6E97AB9219D2496F0B390A35 Content-Type: text/x-patch; charset=UTF-8; name="0001-Tweak-mutability-doc-a-bit-more.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Tweak-mutability-doc-a-bit-more.patch" >From 49bc5a63f7d6178f136d9e28bcacda3acfc375d3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 24 Apr 2020 19:19:31 -0700 Subject: [PATCH] Tweak mutability doc a bit more Inspired by a comment from Michael Heerdegen (Bug#40671#114). * doc/lispref/objects.texi (Constants and Mutability): Tweak further. --- doc/lispref/objects.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 1eda94ab63..b4e9ff4411 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2401,8 +2401,8 @@ Constants and Mutability call @code{(make-string 3 ?a)} yields a mutable string that can be changed via later calls to @code{aset}. - A mutable object can become constant if it is passed to the -@code{eval} function, because a program should not modify an object + A mutable object can become constant if it is part of an expression +that is evaluated, because a program should not modify an object that is being evaluated. The reverse does not occur: constant objects should stay constant. -- 2.17.1 --------------6E97AB9219D2496F0B390A35-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 02:41: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 To: Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Richard Stallman Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15877824193184 (code B ref 40671); Sat, 25 Apr 2020 02:41:01 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 02:40:19 +0000 Received: from localhost ([127.0.0.1]:58303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSAjr-0000pH-4G for submit@debbugs.gnu.org; Fri, 24 Apr 2020 22:40:19 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:40319) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSAjo-0000p1-KZ for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 22:40:17 -0400 Received: by mail-wm1-f45.google.com with SMTP id u16so13769914wmc.5 for <40671@debbugs.gnu.org>; Fri, 24 Apr 2020 19:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SVW3DrLrXaYyKAK/9BSJSB+pzWUI9As054wmg0eefl0=; b=UhTEAxOhtYse1+RSP5iAUq8+8raF5rpULQWr6N36Xi8WCGhf+R/tu2j1h9aDzj6y4F lHwCYIJMDuBIr/Kg0rARs+Oqb0squjsZggaPmk0WlprzxjWdyY2I8cpjCElmTUbxdEJm ObGgkXbSdbHpCnu6iRI7GxXnG0kUmBGOgdxZl5CqEVn881PGYkNl4BDfxk+hEeF0e+xE 3kKCQj4smREv/CiT2pKjLVZGQkq1vZq2d+HJdAdTze90SSICg8kyffSCTB3xZ48QO7dK kqcDAx6WmsUp2tABTNxZQ9OBZznoZP4MelDkchNCPWtopVPnBXcMu76gy6z3J3D+T2vP L6jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SVW3DrLrXaYyKAK/9BSJSB+pzWUI9As054wmg0eefl0=; b=hpJjjq+tfxrdtaacTtzCQFKsetreHNlxu9oOeJhXsWyGjzImbhSHvz1UE/GSKmmo32 XOiZ9T9tYjaRPlLtPTb8zDMQrj1nTRf4wUbkOajyiHKi+E6XeBLxpxLWF2T9N9aM6VY1 Wl5JBria4sUrv5aOGK3Vyh1E6/AXncuu1U35OUVjd/wGLywc/5w8BuIlrcQ/9sHgHL4K w+EkkGDDoWI0ph+IHHQvbNziHdDiG0cTkUfojFEj/pbuD86KkiKA2MOvESdoOChFli4B YVmx5P/V4LWs23QEFB2FB//cJ+XuqWFGd3iHdb3BS5aR0dsApQwH9gLCKWrWratvcRpK SHeg== X-Gm-Message-State: AGi0PuagdUCe8Er4In3bKopgh+f73PHlF7FJNE8L2dOI35wzSdXIeTiO KlqENi2/JkY9gAZqHeXja8tiapUtwlQ= X-Google-Smtp-Source: APiQypJCgO9KLKmG5TWe43/IDObwLf+2wdGGxbFjCBjK1XFo8tKJVIjG0N/fi5yhr2N+7Aa/Bf1Z7g== X-Received: by 2002:a1c:3b0a:: with SMTP id i10mr13191418wma.26.1587782410513; Fri, 24 Apr 2020 19:40:10 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id h16sm12287303wrw.36.2020.04.24.19.40.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Apr 2020 19:40:09 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> From: Dmitry Gutov Message-ID: <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> Date: Sat, 25 Apr 2020 05:40:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 25.04.2020 05:21, Paul Eggert wrote: > That depends on what other programming languages we're talking about. The > current use of 'constant' in the manual corresponds reasonably closely to > 'const' objects in C and C++. Since we're talking about non-scalar values, do you mean constant pointers to (generally) mutable objects? Or a constant aggregate of mutable objects? When a value is constant in C or C++, you can't change it. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 03:21: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 To: Dmitry Gutov , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Richard Stallman Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15877848186930 (code B ref 40671); Sat, 25 Apr 2020 03:21:02 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 03:20:18 +0000 Received: from localhost ([127.0.0.1]:58316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSBMX-0001nh-UB for submit@debbugs.gnu.org; Fri, 24 Apr 2020 23:20:18 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSBMV-0001nP-QI for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 23:20:16 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B864716008D; Fri, 24 Apr 2020 20:20:09 -0700 (PDT) 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 cSkRQbebXYKu; Fri, 24 Apr 2020 20:20:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 015AA1600D3; Fri, 24 Apr 2020 20:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 Lmz6u8poqA7h; Fri, 24 Apr 2020 20:20:08 -0700 (PDT) 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 AFC9716008D; Fri, 24 Apr 2020 20:20:08 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> Date: Fri, 24 Apr 2020 20:20:08 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/24/20 7:40 PM, Dmitry Gutov wrote: >> That depends on what other programming languages we're talking about. The >> current use of 'constant' in the manual corresponds reasonably closely to >> 'const' objects in C and C++. > > Since we're talking about non-scalar values, do you mean constant pointers to > (generally) mutable objects? Or a constant aggregate of mutable objects? Neither. I mean a constant object, e.g., the array of chars denoted by the string literal "abc" in C. > When a value is constant in C or C++, you can't change it. Yes, you can't change it in a portable program, because if you attempt to change it the resulting behavior is undefined. The attempt might succeed so that the "constant" is changed, or you might get a core dump, or you might get an exception, or something else might happen. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 03:39: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 To: Mattias =?UTF-8?Q?Engdeg=C3=83=C2=A5rd?= Cc: michael_heerdegen@web.de, ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org Reply-To: rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158778589716850 (code B ref 40671); Sat, 25 Apr 2020 03:39:02 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 03:38:17 +0000 Received: from localhost ([127.0.0.1]:58339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSBdx-0004Ni-C9 for submit@debbugs.gnu.org; Fri, 24 Apr 2020 23:38:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSBdv-0004NT-LP for 40671@debbugs.gnu.org; Fri, 24 Apr 2020 23:38:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46383) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSBdp-0006UR-T8; Fri, 24 Apr 2020 23:38:09 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jSBdo-0000Vz-Vb; Fri, 24 Apr 2020 23:38:09 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: (message from Mattias =?UTF-8?Q?Engdeg=C3=83=C2=A5rd?= on Fri, 24 Apr 2020 18:39:29 +0200) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> Message-Id: Date: Fri, 24 Apr 2020 23:38:08 -0400 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > That is an interesting point. What is the difference between > CANNOT and SHOULD NOT, operationally? To the user, nothing; there > is no gain from disobeying our advice. It makes a big practical difference to programmers. CANNOT means "If you try to chsnge it, it won't change", and probably also "That will trigger a diagnostic." SHOULOD NOT means "if you try to chsnge it, it will give you no diagnostic and the value will seem to have changed, but afterward bizarre things may happen." -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Andreas Schwab Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 06:01: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158779444831082 (code B ref 40671); Sat, 25 Apr 2020 06:01:01 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 06:00:48 +0000 Received: from localhost ([127.0.0.1]:58372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSDrs-00085G-FP for submit@debbugs.gnu.org; Sat, 25 Apr 2020 02:00:48 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:54958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSDrq-000857-Km for 40671@debbugs.gnu.org; Sat, 25 Apr 2020 02:00:47 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 498L4X3cQzz1qsjf; Sat, 25 Apr 2020 08:00:44 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 498L4X2grlz1qrWg; Sat, 25 Apr 2020 08:00:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id Fimof5V3v-pz; Sat, 25 Apr 2020 08:00:43 +0200 (CEST) X-Auth-Info: UZjTpjXqpHFM95Cd7JYHY5LxFtY1s1a4OrVrY9eFGTSrDzttpuYsf8fHADHautWX Received: from hase.home (ppp-46-244-168-90.dynamic.mnet-online.de [46.244.168.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Sat, 25 Apr 2020 08:00:43 +0200 (CEST) Received: by hase.home (Postfix, from userid 1000) id 25462102507; Sat, 25 Apr 2020 08:00:39 +0200 (CEST) From: Andreas Schwab References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> X-Yow: Vote for ME -- I'm well-tapered, half-cocked, ill-conceived and TAX-DEFERRED! Date: Sat, 25 Apr 2020 08:00:37 +0200 In-Reply-To: (Paul Eggert's message of "Fri, 24 Apr 2020 19:22:22 -0700") Message-ID: <87mu70nlyy.fsf@linux-m68k.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) On Apr 24 2020, Paul Eggert wrote: > diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi > index 1eda94ab63..b4e9ff4411 100644 > --- a/doc/lispref/objects.texi > +++ b/doc/lispref/objects.texi > @@ -2401,8 +2401,8 @@ Constants and Mutability > call @code{(make-string 3 ?a)} yields a mutable string that can be > changed via later calls to @code{aset}. > > - A mutable object can become constant if it is passed to the > -@code{eval} function, because a program should not modify an object > + A mutable object can become constant if it is part of an expression > +that is evaluated, because a program should not modify an object > that is being evaluated. The reverse does not occur: constant objects "that is evaluated ... that is being evaluated" is saying the same thing twice. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 18:24: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 To: Andreas Schwab Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158783902312896 (code B ref 40671); Sat, 25 Apr 2020 18:24:02 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 18:23:43 +0000 Received: from localhost ([127.0.0.1]:60328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSPSp-0003Lw-5C for submit@debbugs.gnu.org; Sat, 25 Apr 2020 14:23:43 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSPSn-0003La-2d for 40671@debbugs.gnu.org; Sat, 25 Apr 2020 14:23:41 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 131E4160065; Sat, 25 Apr 2020 11:23:34 -0700 (PDT) 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 nufw7qtCZ_Ay; Sat, 25 Apr 2020 11:23:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 305061600DA; Sat, 25 Apr 2020 11:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 pxyE5NZGjgGm; Sat, 25 Apr 2020 11:23:33 -0700 (PDT) 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 CCB01160065; Sat, 25 Apr 2020 11:23:32 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <87mu70nlyy.fsf@linux-m68k.org> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <98a42c8f-0ac7-8c47-0a5a-67b35ec0ddf7@cs.ucla.edu> Date: Sat, 25 Apr 2020 11:23:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87mu70nlyy.fsf@linux-m68k.org> Content-Type: multipart/mixed; boundary="------------4707312CAC908F56FF7670E0" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------4707312CAC908F56FF7670E0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/24/20 11:00 PM, Andreas Schwab wrote: > "that is evaluated ... that is being evaluated" is saying the same thing > twice. Thanks for catching that; I installed the attached. --------------4707312CAC908F56FF7670E0 Content-Type: text/x-patch; charset=UTF-8; name="0001-Remove-doc-duplication.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Remove-doc-duplication.patch" >From 9621a4840a27d2fb0283a4faa5aadd7febaeaf6b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 25 Apr 2020 11:22:01 -0700 Subject: [PATCH] Remove doc duplication * doc/lispref/objects.texi (Constants and Mutability): Remove duplication. From a suggestion by Andreas Schwab (Bug#40671#150). --- doc/lispref/objects.texi | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index b4e9ff4411..1d5b2c690f 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2402,8 +2402,7 @@ Constants and Mutability changed via later calls to @code{aset}. A mutable object can become constant if it is part of an expression -that is evaluated, because a program should not modify an object -that is being evaluated. The reverse does not occur: constant objects +that is evaluated. The reverse does not occur: constant objects should stay constant. Trying to modify a constant variable signals an error -- 2.17.1 --------------4707312CAC908F56FF7670E0-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 18:27: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 To: rms@gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=83=C2=A5rd?= Cc: michael_heerdegen@web.de, ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158783917313139 (code B ref 40671); Sat, 25 Apr 2020 18:27:01 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 18:26:13 +0000 Received: from localhost ([127.0.0.1]:60332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSPVF-0003Pr-Hv for submit@debbugs.gnu.org; Sat, 25 Apr 2020 14:26:13 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSPVE-0003Pc-B5 for 40671@debbugs.gnu.org; Sat, 25 Apr 2020 14:26:12 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 04526160065; Sat, 25 Apr 2020 11:26:07 -0700 (PDT) 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 ywRBlIOsK_rF; Sat, 25 Apr 2020 11:26:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 46F4A1600DA; Sat, 25 Apr 2020 11:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 RqG06oWuvfb5; Sat, 25 Apr 2020 11:26:06 -0700 (PDT) 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 DE09A160065; Sat, 25 Apr 2020 11:26:05 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <0023229e-4ef1-79f0-9c1d-405363fbfa46@cs.ucla.edu> Date: Sat, 25 Apr 2020 11:26:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/24/20 8:38 PM, Richard Stallman wrote: > SHOULOD NOT means "if you try to change it, it will give you no > diagnostic and the value will seem to have changed, but afterward > bizarre things may happen." Here SHOULD NOT simply means "if you try to change it, afterward bizarre things may happen". This includes the meaning you gave, and also includes some other meanings. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 19:31: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 To: Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Richard Stallman Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158784305719168 (code B ref 40671); Sat, 25 Apr 2020 19:31:02 +0000 Received: (at 40671) by debbugs.gnu.org; 25 Apr 2020 19:30:57 +0000 Received: from localhost ([127.0.0.1]:60385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSQVf-0004ys-4j for submit@debbugs.gnu.org; Sat, 25 Apr 2020 15:30:57 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:43294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSQVc-0004ye-SL for 40671@debbugs.gnu.org; Sat, 25 Apr 2020 15:30:41 -0400 Received: by mail-wr1-f45.google.com with SMTP id i10so15671898wrv.10 for <40671@debbugs.gnu.org>; Sat, 25 Apr 2020 12:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JbMEguKDHSTLNzAm41bb0nApP4O8vm0cMgzS8As31VU=; b=b0VC+z3CH9E8saxK0mtPr7bRnXJTfll0+B9TNPSYWJPvBtmjqCW7/31sJc4FRtUXHa 6Ur3rs0CUXr9Ykr1WnWdScarAJp2vCZCeUrnt9VI+0jlamTiKzzdL4oUaNOIeiHdX/ym Y3UAdE/pezUzVf/bcz9Vu+hPgo45U8fKr1vp//7wm1lR5OJ4d/NIDH/b7/np2kufPHqh 1NZ6PdpB6YlZfkH60o9BUj49fTLs3qfRZiG1BteySTmK37gf4Jeh4h54MzZcxe8mY904 Ifc3YzT54bwVpYzBf4WR461j2INj4EvHxJ1yBGI7k7WwZSrZWt4jpKNjTb8w+RlhrQDu OP9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JbMEguKDHSTLNzAm41bb0nApP4O8vm0cMgzS8As31VU=; b=GssiC1zvuf05pcGUhAwZXABW8BImryE7ddArDUg4kztE5KmNmghZey2mhtULhCU43J sPQ0BcLh7Eb07MHjHcS+iTpdHVmH0/p4QFJHPuPG8dvFD6SRxTGSpZeGPZHjfM51BEQ/ HtoFU7RsIINn0qsWfaV9b8lU3HdQpU+CNkkikznOkQbG3Z3Qb7b6Sy3jOVXqkWc60wsH MYxvGCkztfCTpbyj4aOGLtM4FTGYLhJEzqnDzuOq3It81+h7ioAvrxXsA+U+77yCa9+C 1+vg+FkuEHV6+8geNMMb1woaadMK1RyNbBViCDhf+tBjUDM7LkGf2JmYDgz0WxIiD/IR Remg== X-Gm-Message-State: AGi0PuY1D2IIn7znrQY3UhXOHpLfaobQYgNAv3N+Zc7lxbBESLZvRK7i 0m0lIO5Wl+rE/mTqGxm5jHtTdF8xcyQ= X-Google-Smtp-Source: APiQypKqzmHzD7Fld5NVuMniUlUS4i6dTqdXZ8+cZoegliXTuBlz0xGKoG/5iWmXPlFGoN5DFKNWSA== X-Received: by 2002:a5d:4b90:: with SMTP id b16mr19535045wrt.16.1587843035020; Sat, 25 Apr 2020 12:30:35 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id t20sm7376550wmi.2.2020.04.25.12.30.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Apr 2020 12:30:34 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> From: Dmitry Gutov Message-ID: <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> Date: Sat, 25 Apr 2020 22:30:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 25.04.2020 06:20, Paul Eggert wrote: >> When a value is constant in C or C++, you can't change it. > Yes, you can't change it in a portable program, because if you attempt to change > it the resulting behavior is undefined. The attempt might succeed so that the > "constant" is changed, or you might get a core dump, or you might get an > exception, or something else might happen. Might succeed? Will it even compile? From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 03:50: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 To: Dmitry Gutov , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Richard Stallman Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158787297610633 (code B ref 40671); Sun, 26 Apr 2020 03:50:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 03:49:36 +0000 Received: from localhost ([127.0.0.1]:60707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSYIR-0002lR-UR for submit@debbugs.gnu.org; Sat, 25 Apr 2020 23:49:36 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49380) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSYIQ-0002lD-FB for 40671@debbugs.gnu.org; Sat, 25 Apr 2020 23:49:34 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B84DF16008D; Sat, 25 Apr 2020 20:49:28 -0700 (PDT) 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 DQ_slYK5JX1a; Sat, 25 Apr 2020 20:49:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EBF2F1600D1; Sat, 25 Apr 2020 20:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 XohxBRWMz90H; Sat, 25 Apr 2020 20:49:27 -0700 (PDT) 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 8A0F616008D; Sat, 25 Apr 2020 20:49:27 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Sat, 25 Apr 2020 20:49:27 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/25/20 12:30 PM, Dmitry Gutov wrote: > On 25.04.2020 06:20, Paul Eggert wrote: >>> When a value is constant in C or C++, you can't change it. >> Yes, you can't change it in a portable program, because if you attempt to change >> it the resulting behavior is undefined. The attempt might succeed so that the >> "constant" is changed, or you might get a core dump, or you might get an >> exception, or something else might happen. > > Might succeed? Will it even compile? Yes, although the C/C++ program must type-check and satisfy all other static constraints of course (otherwise it won't compile). Here's a simple example: #include int main (void) { return !strcpy ("a", "b"); } This function attempts to modify the "a" string constant, so it might dump core, or might return 0, or might do other things. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 14:04: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 To: Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Richard Stallman Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158790983023204 (code B ref 40671); Sun, 26 Apr 2020 14:04:01 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 14:03:50 +0000 Received: from localhost ([127.0.0.1]:33845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jShsr-00062B-S8 for submit@debbugs.gnu.org; Sun, 26 Apr 2020 10:03:50 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:54899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jShsq-00061z-0t for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 10:03:48 -0400 Received: by mail-wm1-f41.google.com with SMTP id h4so3303845wmb.4 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 07:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=d523qBrFOwuUmdwaon0IX7PKJz7HS8T31O5O4ecQyqg=; b=os3gPycQ26aC8ulLwbNIau5PPZxdFmY6UqUADtIw6qh7wNMw9kgSHZg7vU3eoc37Ha tTlk2J36cxQuFp+33T19J/2LNzzTWPatNavotfigeUwyjD/D+FkVQu6UjHcv07ha/MaN P5IjUILn4ve9rL5hLKS8IPcAtTSUAtFYXCsU22MBih6G4lTMs7rp4b/PDOu2eh2CIPTG WNeUISVL2xeSL+vW4X0BK23jDj58eRX6TXN51L6RkgQdSugZzSZ9b2V0VQQfEyFBKM/y eVSK1sJL2FPD10lx87uz2i0AKuJuhCauoqf9fSpIYNeMI3//BFIm8ghg02i3kNu8NdOg EdoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=d523qBrFOwuUmdwaon0IX7PKJz7HS8T31O5O4ecQyqg=; b=foM66XlB1a98p+YkvQjgdaDHqYuHulthMdnXNtsUll3rdgRI5ejyW2xBuMPXVUGRRf i6JZk1al5ssf+/nQPUoryryOaMEwKsO96lxRcXO7czwOmX+vAoqElIx7wSeSAO7aEWl8 mgI5w78jjlxl4Gu5uD4XWlEaZRp8RtwybyPH62EqQJxmwcGg+4k4Hz+BdJaLDz16q1Tc uwBXMGBZ9sA305zKu6iYRlmYkstHVQvRC5lbqm9C0qq00+B99HzrokG9s9NI0CzOPAdZ XcTXZZIwttj1g4yWq8OjLWWkRvXHO76v2SMVfFAphsuQaiVSaYMzRSIVl8MQpK8hajxm UO8Q== X-Gm-Message-State: AGi0PuaxkJ6j2v6oVOpQVmVnxmdO8qq0uclame+4TN+5+9k8Nve3dwdQ L8a04+vZmpQ6kLd70q70CVQCl5tfE88= X-Google-Smtp-Source: APiQypIKHpvn2rvzhvpFCwdpIF42X5Nji/exCqcBSkB9wIEbxKdYhW4+ogiXR6QJweOPSidr7IGTXA== X-Received: by 2002:a1c:6787:: with SMTP id b129mr22111855wmc.165.1587909821656; Sun, 26 Apr 2020 07:03:41 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id j4sm16479256wrm.85.2020.04.26.07.03.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 07:03:41 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> From: Dmitry Gutov Message-ID: Date: Sun, 26 Apr 2020 17:03:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 26.04.2020 06:49, Paul Eggert wrote: >> Might succeed? Will it even compile? > Yes, although the C/C++ program must type-check and satisfy all other static > constraints of course (otherwise it won't compile). Here's a simple example: > > #include > int main (void) { return !strcpy ("a", "b"); } > > This function attempts to modify the "a" string constant, so it might dump core, > or might return 0, or might do other things. g++ string_const.c++ string_const.c++: In function ‘int main()’: string_const.c++:2:35: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings] 2 | int main (void) { return !strcpy ("a", "b"); } I have no idea why it only shows a compile-time warning (probably because of backward-compatibility concerns because in C a string is *not* a const, just a source of undefined behavior), but the warning, at least, is there for the user to see. Not just in the manual. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 14:20: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 To: Dmitry Gutov Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158791080127577 (code B ref 40671); Sun, 26 Apr 2020 14:20:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 14:20:01 +0000 Received: from localhost ([127.0.0.1]:33863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSi8Q-0007Ac-Qg for submit@debbugs.gnu.org; Sun, 26 Apr 2020 10:20:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSi8M-0007AO-MS for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 10:19:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43728) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSi8F-0004cc-K3; Sun, 26 Apr 2020 10:19:43 -0400 Received: from [176.228.60.248] (port=4559 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSi88-0004SO-IH; Sun, 26 Apr 2020 10:19:37 -0400 Date: Sun, 26 Apr 2020 17:19:28 +0300 Message-Id: <83zhay5nyn.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Dmitry Gutov on Sun, 26 Apr 2020 17:03:38 +0300) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Dmitry Gutov > Date: Sun, 26 Apr 2020 17:03:38 +0300 > Cc: Michael Heerdegen , ke.vigouroux@laposte.net, > 40671@debbugs.gnu.org > > > #include > > int main (void) { return !strcpy ("a", "b"); } > > > > This function attempts to modify the "a" string constant, so it might dump core, > > or might return 0, or might do other things. > > g++ string_const.c++ > string_const.c++: In function ‘int main()’: > string_const.c++:2:35: warning: ISO C++ forbids converting a string > constant to ‘char*’ [-Wwrite-strings] > 2 | int main (void) { return !strcpy ("a", "b"); } Did you try compiling that as a C program, not a C++ program? If I force the C compiler to use -Wwrite-strings, then I get: gcc -Wwrite-strings string_const.c string_const.c: In function 'main': string_const.c:2:35: warning: passing argument 1 of 'strcpy' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] int main (void) { return !strcpy ("a", "b"); } ^~~ In file included from string_const.c:1:0: d:\usr\include\string.h:79:40: note: expected 'char *' but argument is of type 'const char *' _CRTIMP __cdecl __MINGW_NOTHROW char *strcpy (char *, const char *); ^~~~~~ but even that goes away if I modify the program as follows: #include int main (void) { return !strcpy ((char *)"a", "b"); } From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 14:36: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 To: Eli Zaretskii Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158791171129068 (code B ref 40671); Sun, 26 Apr 2020 14:36:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 14:35:11 +0000 Received: from localhost ([127.0.0.1]:33879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSiN9-0007Yg-Py for submit@debbugs.gnu.org; Sun, 26 Apr 2020 10:35:11 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:38291) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSiN8-0007Xu-2h for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 10:35:06 -0400 Received: by mail-wr1-f47.google.com with SMTP id x17so16645423wrt.5 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 07:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QuR1zwJr3lIhJr4qnW1C3dn/hjQgnJqATRyYc32Op/w=; b=DrR+VxPcox5MBMkc6vlf2zB296zoAwe225cLNJRylHm7PQ+3PHNEJMtEx/hh+UgH4T Oa4GjxG/WEArLMSm0LwEuxK+da8NT29rCjjonaGZ8imrhWFacmdIFK3zgN9Me9zKtza9 tCfsv1fWImrYIGZu8cxBSVz8OoJaBZ6mVHf9H+qsB2qiqDJDQ4Kdi7UXae1GIHyhRJpj HLjtHc1KDiWBwzdJ2ESvwDAliVsvrt0PNxaXZ+zXkgPEIADK+2uYP/c2DBn9tw/9FvyN iRmaPRStCbdEPtmM3C2MUAndvfDrqw/yEwbBNmd1PmLRZJo27uuimUpfw12qTXqN/CWU FjIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QuR1zwJr3lIhJr4qnW1C3dn/hjQgnJqATRyYc32Op/w=; b=CE8wACncBJeEqKV4eK8ZKFUXkb3PmLujXf61sJH5pSZWQ00hrbuJxUm8EJqUl5lxsC qC/f7XSpHsvO+b+Ii/DziBkG+fRu/gB4+CkjaMhHF/oYGBrh0QI48U+fktL8Z28hjH0i OZX+VC0vHuiPVAACO6QyPcxfFmcEN5z7ULKwj8DSY3L4cvtHgSUMM8UHygTB9G4vQuO4 LB/7Ksxvtg4IPQ0AFPWJMKPVHHvsomaEazcapi4yF4+ltvM9viqwxt6vqt/Uf/6Sl0dd fpeH/JHWeusMjDkrfLtIPTsHQoIkNkwFWcNumyQ6bakAApLq2OROIczUaHMYVbl86ZZb 79jw== X-Gm-Message-State: AGi0Pua5c4HCgDQ8rf7cK3sqGFV6jJ+IguJOUs2Ghz/KF4pA+ZzzNfv+ 7onySM0NqNkeYJn5EcFSzfVZdtb+PYQ= X-Google-Smtp-Source: APiQypINAKq6iijXj9IxCKnxh9sQT13yuZf+YKfv7q9NVJobb/W1a3DBPf3B7NOA9UR8QTdCJv3zog== X-Received: by 2002:adf:9564:: with SMTP id 91mr23171639wrs.246.1587911699987; Sun, 26 Apr 2020 07:34:59 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id m15sm11374104wmc.35.2020.04.26.07.34.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 07:34:59 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <83zhay5nyn.fsf@gnu.org> From: Dmitry Gutov Message-ID: <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> Date: Sun, 26 Apr 2020 17:34:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <83zhay5nyn.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 26.04.2020 17:19, Eli Zaretskii wrote: > Did you try compiling that as a C program, not a C++ program? As C++. From what I understand, in C string literals are not "const", it's just UB to modify them. > but even that goes away if I modify the program as follows: > > #include > int main (void) { return !strcpy ((char *)"a", "b"); } If you go out of your way to avoid warnings, then indeed, the compiler won't show them. And typecasts are an easy way to turn compilation errors into runtime errors, in general. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 15:47: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 To: Dmitry Gutov Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158791600211277 (code B ref 40671); Sun, 26 Apr 2020 15:47:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 15:46:42 +0000 Received: from localhost ([127.0.0.1]:33946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSjUM-0002vl-0D for submit@debbugs.gnu.org; Sun, 26 Apr 2020 11:46:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSjUK-0002vZ-N9 for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 11:46:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44867) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSjUE-0006YK-8u; Sun, 26 Apr 2020 11:46:30 -0400 Received: from [176.228.60.248] (port=1989 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSjU1-0002Od-9E; Sun, 26 Apr 2020 11:46:17 -0400 Date: Sun, 26 Apr 2020 18:46:11 +0300 Message-Id: <83pnbu5jy4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> (message from Dmitry Gutov on Sun, 26 Apr 2020 17:34:56 +0300) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <83zhay5nyn.fsf@gnu.org> <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: eggert@cs.ucla.edu, mattiase@acm.org, rms@gnu.org, > michael_heerdegen@web.de, ke.vigouroux@laposte.net, 40671@debbugs.gnu.org > From: Dmitry Gutov > Date: Sun, 26 Apr 2020 17:34:56 +0300 > > > #include > > int main (void) { return !strcpy ((char *)"a", "b"); } > > If you go out of your way to avoid warnings, then indeed, the compiler > won't show them. > > And typecasts are an easy way to turn compilation errors into runtime > errors, in general. I think this shows the difference between CANNOT and SHOULD NOT, wrt constants. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 16:03: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 To: Eli Zaretskii Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158791694112878 (code B ref 40671); Sun, 26 Apr 2020 16:03:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 16:02:21 +0000 Received: from localhost ([127.0.0.1]:33984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSjjV-0003Lb-Ra for submit@debbugs.gnu.org; Sun, 26 Apr 2020 12:02:21 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:51515) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSjjU-0003LN-Ca for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 12:02:17 -0400 Received: by mail-wm1-f45.google.com with SMTP id x4so16784542wmj.1 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 09:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lM5O+uG7rgOpLFOF5hY0jn+znfII6Ny3AE0+qYbjMOo=; b=sqfAC2vOkRIx0mrcPGJSRJukvXju/iaW4BXYSiZ10DmUyBS8w3IBcaFYYqEMB3t0hm qUxiYvFAZ4+8QvTaz+7sGXTP75Wbq0xQvHVP40XgikNNCq+QcmWJe0YD3UZtK+3WjJoL jd/59MlOpcF4gmN2aIM38P/VwP5r/GHrYktoOF0aM+L9+WKI72nBuRI2RqZYAFc4X/4L WYa+h2+jHlcJFZ6BQ3VmfMYMUYQ12pW57o3CCS/oS1fhPM9OIzhyAEUcZseVfA4R7fCo 89s4+L/s6Rux5z7JMPTwpOFa5QZW0bvwtPHSTdtZl/ZrUZK4ffugQbTY68cepf12JVem aTIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lM5O+uG7rgOpLFOF5hY0jn+znfII6Ny3AE0+qYbjMOo=; b=oE55HyqgdB/MH7nqdZqaOBAdkMqRoCg+ioaH9b9ijPr14SRvgYqfIvtwtrSIyESJAC qGsoLRQByBDlL+kwI+4aBJsnpb9xZqc1qvabavAyifg4D5ufTg0g1KmiC7l/iBZCM+E6 lUT8bsVm1yCITCAMQOdx1XH9EXS6cv+5ydEnozVqH9fdtHbrCifkmYOVY41QcfBvcc1W YIsqkSMyzLy2NUiJ5mhl6PDnQEKj66+e1NcxRC4d8/EDrR4fqo1IVIrNRjn0psgglViL 2OKg90S3aYiMRd0H8Khp3sigI/h0x2Psay1f2LvrTLx540PoB4VVy1R2x1yiGek90kN7 rtXQ== X-Gm-Message-State: AGi0PuZNO0vva3mhB7VYjXCXKp/V2dSyMeCuQ/HshcihWFQmMiRL4KCD zlBDs6v3CLwSgWN/WsPms+4= X-Google-Smtp-Source: APiQypLzMTEOSoqBCdB/tS0cnsxoK0i1o9g5wPZsSp0Iy+9uJvxdyiVq/e6lVcrflQ2Drw2hD0A+TQ== X-Received: by 2002:a05:600c:21d6:: with SMTP id x22mr22519242wmj.95.1587916930405; Sun, 26 Apr 2020 09:02:10 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id t17sm16691314wro.2.2020.04.26.09.02.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 09:02:09 -0700 (PDT) References: <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <83zhay5nyn.fsf@gnu.org> <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> <83pnbu5jy4.fsf@gnu.org> From: Dmitry Gutov Message-ID: <51ab1b2d-1b0e-fb65-2abd-d29cfa8461e5@yandex.ru> Date: Sun, 26 Apr 2020 19:02:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <83pnbu5jy4.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 26.04.2020 18:46, Eli Zaretskii wrote: > I think this shows the difference between CANNOT and SHOULD NOT, wrt > constants. I'm not sure I understand the analogy. Anyway, C and C++ have notoriously tricky semantics in edge cases. It's probably not a good idea to use either of them as example for Emacs Lisp. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 16:59: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 To: Dmitry Gutov Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158792033921910 (code B ref 40671); Sun, 26 Apr 2020 16:59:01 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 16:58:59 +0000 Received: from localhost ([127.0.0.1]:34790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSkcI-0005hF-Ko for submit@debbugs.gnu.org; Sun, 26 Apr 2020 12:58:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSkcG-0005h2-EI for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 12:58:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47028) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSkcA-0005L6-3z; Sun, 26 Apr 2020 12:58:46 -0400 Received: from [176.228.60.248] (port=2487 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSkbw-0004tH-0i; Sun, 26 Apr 2020 12:58:33 -0400 Date: Sun, 26 Apr 2020 19:58:24 +0300 Message-Id: <83k1225glr.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <51ab1b2d-1b0e-fb65-2abd-d29cfa8461e5@yandex.ru> (message from Dmitry Gutov on Sun, 26 Apr 2020 19:02:05 +0300) References: <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <83zhay5nyn.fsf@gnu.org> <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> <83pnbu5jy4.fsf@gnu.org> <51ab1b2d-1b0e-fb65-2abd-d29cfa8461e5@yandex.ru> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, > michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org > From: Dmitry Gutov > Date: Sun, 26 Apr 2020 19:02:05 +0300 > > On 26.04.2020 18:46, Eli Zaretskii wrote: > > I think this shows the difference between CANNOT and SHOULD NOT, wrt > > constants. > > I'm not sure I understand the analogy. That program demonstrates that in C one CAN change a "constant" array. But one definitely SHOULD NOT do that. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 17:40: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 To: Eli Zaretskii Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15879227911640 (code B ref 40671); Sun, 26 Apr 2020 17:40:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 17:39:51 +0000 Received: from localhost ([127.0.0.1]:34832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSlFu-0000QN-LZ for submit@debbugs.gnu.org; Sun, 26 Apr 2020 13:39:50 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:33736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSlFs-0000QA-GN for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 13:39:48 -0400 Received: by mail-wm1-f45.google.com with SMTP id v8so14190064wma.0 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 10:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oaCRuhUs6QmEgxnL/gFpo8Kj4qShIBxyJcbvtfHbtWE=; b=GNfvg9bpJluqP44ldauDQgYRpHiSsTFowi2d+EDFmOR0fdNOr5jUG3lqTZ7znGw2rq zP+7Oqi8Rp12Vzer5ahA7V7zhvSX8hoH5ogKo0xp81w8/Bv1I/Ualts2TJJgfC9aRUSL 5VmLlpy2ENkOaYo5V+eq2AswJtDaxHTakRcnvLGhzSoji45wjcIigAZpuKRVH9ikh+bv bYSQFY3HQmu6ZTFvQ9S8JL8PYU82VTG33hWWX43I+RFIQvDJwTHzGTncJVpQqV1dpII0 +nk5lpeJK0wyrqwMjynIMoF6gRgrrTp1ncs9vsJSFR6unZZ4i1C4TG4CaAwDMaP3S/i2 MEtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oaCRuhUs6QmEgxnL/gFpo8Kj4qShIBxyJcbvtfHbtWE=; b=fMk4HkC5wZI48YA7z9xcFycijjwU10S4b6facR7wFNVpkHGRKiKJD/1PDtkmTu3+Qk HVMVGy5AC4zt6P2qNE8VkY/QHocvp1boLG7kyrO2MaZpeJL0a5wCgfNeUiEWGJv4PJJh 8Ry+KVp+D5hu6Z2a/Qa0FQjjuhkSnpMcbHEfUAi/2M+ZZ3sRkCs4tl/eJupiHIAslhrr ka6qrcTQ1d3CLOpWcQXb9A/iF5fwpz5OyMCcaSxnTNhVVFi3yZpYU/zjnkVC3SMxRiWf xq9Ul63wj/bD33rUs3XLo8idsD2cC/0xgGCmmi55Rgr5P6IuCAhLrpFsrBEau+dxbhLi Oibg== X-Gm-Message-State: AGi0PuaSBNpyAkhfnam20EVwIhsGmiZCySqYoxOlSKn+SGBOdJZiPuTf r+UFFcxK1NHuwAGOHSf+Vtk= X-Google-Smtp-Source: APiQypJJA7Ulu7VK1YU5ngZT5QSTvmgQuzOSYMaGMjGOPwDdFUA8iHBdukXJt1k9Bgnu2QFiK1PsSA== X-Received: by 2002:a1c:750a:: with SMTP id o10mr21565517wmc.161.1587922782668; Sun, 26 Apr 2020 10:39:42 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id x23sm11700010wmj.6.2020.04.26.10.39.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 10:39:42 -0700 (PDT) References: <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <83zhay5nyn.fsf@gnu.org> <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> <83pnbu5jy4.fsf@gnu.org> <51ab1b2d-1b0e-fb65-2abd-d29cfa8461e5@yandex.ru> <83k1225glr.fsf@gnu.org> From: Dmitry Gutov Message-ID: <8a4bb621-0fe7-52d5-e6e3-d1a0ec5b6a59@yandex.ru> Date: Sun, 26 Apr 2020 20:39:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <83k1225glr.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 26.04.2020 19:58, Eli Zaretskii wrote: > That program demonstrates that in C one CAN change a "constant" > array. When you first change it to a "non-constant" one, as far as the compiler is concerned? It's an escape hatch. The same way you "can" funcall a string: int main (void) { return ((int(*) (int))"abc")(1); } It will blow up at runtime, of course. Neither will be the case with "constant" Lisp forms we are talking about. No runtime errors (only subtle, hard to investigate bugs from time to time), and no compilation warnings. The only warnings at all will be in the manual. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 18:16: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 To: Dmitry Gutov Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15879249194933 (code B ref 40671); Sun, 26 Apr 2020 18:16:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 18:15:19 +0000 Received: from localhost ([127.0.0.1]:34860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSloB-0001HP-3X for submit@debbugs.gnu.org; Sun, 26 Apr 2020 14:15:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSlo8-0001HB-Fo for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 14:15:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48839) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSlo0-0006W2-EK; Sun, 26 Apr 2020 14:15:04 -0400 Received: from [176.228.60.248] (port=3353 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSlnp-0000uj-UJ; Sun, 26 Apr 2020 14:14:55 -0400 Date: Sun, 26 Apr 2020 21:14:37 +0300 Message-Id: <838sii5d2q.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8a4bb621-0fe7-52d5-e6e3-d1a0ec5b6a59@yandex.ru> (message from Dmitry Gutov on Sun, 26 Apr 2020 20:39:38 +0300) References: <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <83zhay5nyn.fsf@gnu.org> <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> <83pnbu5jy4.fsf@gnu.org> <51ab1b2d-1b0e-fb65-2abd-d29cfa8461e5@yandex.ru> <83k1225glr.fsf@gnu.org> <8a4bb621-0fe7-52d5-e6e3-d1a0ec5b6a59@yandex.ru> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, > michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org > From: Dmitry Gutov > Date: Sun, 26 Apr 2020 20:39:38 +0300 > > int main (void) { > return ((int(*) (int))"abc")(1); > } > > It will blow up at runtime, of course. But the previous program will not necessarily blow up at runtime. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 18:33: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 To: Eli Zaretskii Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15879259806597 (code B ref 40671); Sun, 26 Apr 2020 18:33:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 18:33:00 +0000 Received: from localhost ([127.0.0.1]:34877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSm5I-0001iH-67 for submit@debbugs.gnu.org; Sun, 26 Apr 2020 14:33:00 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:43439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSm5H-0001i2-69 for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 14:32:55 -0400 Received: by mail-wr1-f52.google.com with SMTP id i10so17880394wrv.10 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 11:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lAy4DyoTpbp0poBHSyf1cSF0bJQvaEKoWFiTkxeMU7Y=; b=mGdOLKbFMUDdIXfhsZQo+WLukZEPlbzOSlJSDGwAcf2Wv25FZY6EyngdLYr9Sz3gJr lqSrZ+mXN1zZs1VwI/vyfGdn7WejLcAGh228AGUld5SVGzHphx+oPIZ1dmffBIzbqYEj BODBYQhN6WkO0lkz2tHm+wtVPTb66J96saZLVK+42MDAKg7EpXq45L2HabV6r1bthLmH XRYouSNb4VjOJnKI/2L2JSj80qfQkbORwwzFLtpIrjrqwRFG/ffsbYWGFtOdkBriqKE2 lPMWkvREjdt7whd707tOVtBQNEvbsBMLF9M1mFUz4W7zFrmfLJ/oVw0bEyA7z3jldYWb XUKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lAy4DyoTpbp0poBHSyf1cSF0bJQvaEKoWFiTkxeMU7Y=; b=oghVvGQVhdPUb8IFyG2owlqFtiQhJcmmRmW46wxQ6Xsm7CELa/0hBJwDwv+VWBAO+6 X2PTBy/N/tmZnnwC62v3ikSV3YpFwdMSj1PWatkP86hruxR36CHBfBQsNzJKiBrKxg8S dgByIt09MoWbNgLt7KDiKVlng9sdM5FciYWZktIe9GG10k91CcdHypmXT8y/eJr7VDLI nqMrbdHgBD9qCRxYv+Jrwj4M69BYaE/out+ljeZhCKeZ/35BlsAroq+9mia2y6LQ0++R hyLUpevGQQorgwlkIp1WobnlMwkCWYZu9bf0wzYM5UTNmJBSkrA+fTx6SQS2Gr3ptYdq 5nEw== X-Gm-Message-State: AGi0PuZyZTyF+i2iFVKYJWxDi861ZdLgWYjzEL/uuCvtramKqcsGmPhu 4VrGYG6neHyHt8/OCm/Oclc= X-Google-Smtp-Source: APiQypIQiGlia81cehqBwwqf2i89jOOtGRYUBlsLy+N0vF+cvtyKqbo0msYxBsuRfwjgZVdGl5YP9w== X-Received: by 2002:a05:6000:10c4:: with SMTP id b4mr23689903wrx.203.1587925969257; Sun, 26 Apr 2020 11:32:49 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id c190sm12439451wme.4.2020.04.26.11.32.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 11:32:48 -0700 (PDT) References: <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <83zhay5nyn.fsf@gnu.org> <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> <83pnbu5jy4.fsf@gnu.org> <51ab1b2d-1b0e-fb65-2abd-d29cfa8461e5@yandex.ru> <83k1225glr.fsf@gnu.org> <8a4bb621-0fe7-52d5-e6e3-d1a0ec5b6a59@yandex.ru> <838sii5d2q.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Sun, 26 Apr 2020 21:32:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <838sii5d2q.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 26.04.2020 21:14, Eli Zaretskii wrote: >> Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, >> michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org >> From: Dmitry Gutov >> Date: Sun, 26 Apr 2020 20:39:38 +0300 >> >> int main (void) { >> return ((int(*) (int))"abc")(1); >> } >> >> It will blow up at runtime, of course. > > But the previous program will not necessarily blow up at runtime. "not necessarily" is a damnably low qualifier. My point is, that program is using the same instrument as this one, which *will* blow up at runtime. And the instrument is "making the compiler shut up". From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 18:43: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 To: Dmitry Gutov Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15879265627583 (code B ref 40671); Sun, 26 Apr 2020 18:43:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 18:42:42 +0000 Received: from localhost ([127.0.0.1]:34899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmEg-0001yA-I5 for submit@debbugs.gnu.org; Sun, 26 Apr 2020 14:42:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmEe-0001xx-Qi for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 14:42:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49344) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSmEW-00026j-Nt; Sun, 26 Apr 2020 14:42:29 -0400 Received: from [176.228.60.248] (port=1177 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSmE9-0005Xb-Rq; Sun, 26 Apr 2020 14:42:07 -0400 Date: Sun, 26 Apr 2020 21:41:57 +0300 Message-Id: <837dy25bt6.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Dmitry Gutov on Sun, 26 Apr 2020 21:32:45 +0300) References: <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <83zhay5nyn.fsf@gnu.org> <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> <83pnbu5jy4.fsf@gnu.org> <51ab1b2d-1b0e-fb65-2abd-d29cfa8461e5@yandex.ru> <83k1225glr.fsf@gnu.org> <8a4bb621-0fe7-52d5-e6e3-d1a0ec5b6a59@yandex.ru> <838sii5d2q.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, > michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org > From: Dmitry Gutov > Date: Sun, 26 Apr 2020 21:32:45 +0300 > > My point is, that program is using the same instrument as this one, > which *will* blow up at runtime. No, it isn't the same instrument. Your program constructs a function call using address that has no valid instructions. Paul's program does nothing like that, it just attempts to write to a data address which may or may not be in write-protected storage. So your program will always blow up, whereas the other one will only blow up if the memory is write-protected. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 18:54: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 To: Eli Zaretskii Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15879271998700 (code B ref 40671); Sun, 26 Apr 2020 18:54:01 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 18:53:19 +0000 Received: from localhost ([127.0.0.1]:34917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmOw-0002GC-T6 for submit@debbugs.gnu.org; Sun, 26 Apr 2020 14:53:18 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:38025) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmOv-0002Fz-SM for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 14:53:14 -0400 Received: by mail-wr1-f54.google.com with SMTP id x17so17197548wrt.5 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 11:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=63SMauPbwUockK46BmrzbC8ex4r93XN1IZgGMRktRBM=; b=feAxYfEfNtoYPvepmIH8vrhGPDENUHLYUXCnwkUu7q5DN+7+vgg7P5sZV8by47GA6r I8b9brY5vUvKOmlAwbQkY7ZN47W3B4kt5HAfKWc3nvUwXU6t6IGPthVmdvi9dPSXhsHZ F/pGpR33M9gVlAmWZQsCv/ceKYWV38clJscFtRis9F6vLivzXQTmD1bx0XV3GhVw98Hj aWPVoSuGDJE0/GcSYx/aO1J1ouLXw0K7avaARrwBA9BhEGNGj6EEFvDBzOTusXmCtLaU gZEq7Snar3JYUhb9+pVsJCszOsGQS7O8I7ZIDRIuHIsBCHL9nFOBEbDYhuLo8J+DhR1h vT0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=63SMauPbwUockK46BmrzbC8ex4r93XN1IZgGMRktRBM=; b=h0yrNgu3FXYT0jg/qGsqEVFXtVLKl635ay7jBECFYyNlFVjVeUkWuOMF8I0Nws8gRc FWyV4eNlZwOyTDPILyNQh4vG3K3ofzqjFKFj8Q4JkR1IniTlEWjbSG31WGGU15cih13K aa7YYT0kSq07hs4j9lsNKfdktV8LNpocNBPEvfDyIhOUxEFbGK5oIH+b89n+CAH5EPRG YoVSla7U0X+qAuH/tZFkT6+XokwawkKOh0jlfD/l60GCYK+ghb/ivcjWTWlQ0lZH2o0+ M3GNr5lPB6ZkyMX9gbfroksx7c3PpmsmP9cfwlFQ4a/yyEnZK9UpL/McHOsTkuLwwj0p asQQ== X-Gm-Message-State: AGi0PuaDMytkalqYUnAIa0UCWCnnCYrNshYUPEXVb/7Pg3hdLNSsFPJ+ gM8qk0vgtntwPhtCsN+dZkI= X-Google-Smtp-Source: APiQypJQ7NvDYTta601bb5G5M9Eowk5PENTz6hGMjzOJ8Hr4HVnS4ZO4Ycgigoz32giU9E/JkuEDUg== X-Received: by 2002:a5d:408d:: with SMTP id o13mr25069615wrp.249.1587927187949; Sun, 26 Apr 2020 11:53:07 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id r17sm17478871wrn.43.2020.04.26.11.53.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 11:53:07 -0700 (PDT) References: <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <83zhay5nyn.fsf@gnu.org> <77612744-6de9-3cb8-6d63-1cb9898eb3e1@yandex.ru> <83pnbu5jy4.fsf@gnu.org> <51ab1b2d-1b0e-fb65-2abd-d29cfa8461e5@yandex.ru> <83k1225glr.fsf@gnu.org> <8a4bb621-0fe7-52d5-e6e3-d1a0ec5b6a59@yandex.ru> <838sii5d2q.fsf@gnu.org> <837dy25bt6.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Sun, 26 Apr 2020 21:53:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <837dy25bt6.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 26.04.2020 21:41, Eli Zaretskii wrote: >> Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, >> michael_heerdegen@web.de, mattiase@acm.org, rms@gnu.org >> From: Dmitry Gutov >> Date: Sun, 26 Apr 2020 21:32:45 +0300 >> >> My point is, that program is using the same instrument as this one, >> which *will* blow up at runtime. > > No, it isn't the same instrument. Your program constructs a function > call using address that has no valid instructions. Paul's program > does nothing like that, it just attempts to write to a data address > which may or may not be in write-protected storage. So your program > will always blow up, whereas the other one will only blow up if the > memory is write-protected. I was imprecise. The program is doing a different thing. But the programmer is using the same instrument in both cases to make it compile. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 18:58: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15879274699126 (code B ref 40671); Sun, 26 Apr 2020 18:58:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 18:57:49 +0000 Received: from localhost ([127.0.0.1]:34921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmTN-0002N8-Bd for submit@debbugs.gnu.org; Sun, 26 Apr 2020 14:57:49 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmTL-0002Mu-Ut for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 14:57:48 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5CE9C1600D1; Sun, 26 Apr 2020 11:57:42 -0700 (PDT) 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 JKYPs9b0nY_X; Sun, 26 Apr 2020 11:57:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 949D61600D3; Sun, 26 Apr 2020 11:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 9K8nLP8pH9Fz; Sun, 26 Apr 2020 11:57:41 -0700 (PDT) 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 4EEE21600D1; Sun, 26 Apr 2020 11:57:41 -0700 (PDT) References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Sun, 26 Apr 2020 11:57:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/26/20 7:03 AM, Dmitry Gutov wrote: > g++ string_const.c++ Ah, my example was C-only. Here is an example for both C and C++: #include int main (void) { union { char const *cp; char *p; } u = { "a" }; return !strcpy (u.p, "b"); } This has undefined behavior, and might dump core or might not depending on the implementation. Neither gcc nor g++ issue any warnings in default compilation. Undefined behavior is undesirable and it's not a good thing that Emacs Lisp also has areas that behave like this. Somebody should pry free time to look into fixing them, but that won't be trivial. It appears that portable dumping and other changes have broken some of Emacs's runtime checking in this area. Unfortunately, the relevant code is hairy and any fixes certainly won't happen before the Emacs 27 release. In the meantime it's better to warn users clearly about the gotchas in this area, to help prevent some of the confusion exemplified by Bug#40671. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 19:23: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158792897013201 (code B ref 40671); Sun, 26 Apr 2020 19:23:01 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 19:22:50 +0000 Received: from localhost ([127.0.0.1]:34980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmrZ-0003Qr-Qr for submit@debbugs.gnu.org; Sun, 26 Apr 2020 15:22:50 -0400 Received: from mail-ot1-f50.google.com ([209.85.210.50]:40077) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmrX-0003QR-Tg for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 15:22:48 -0400 Received: by mail-ot1-f50.google.com with SMTP id i27so22451669ota.7 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 12:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6rnRoRb9RZQqFfsdskKGmWsN8KJsse3lrdk8SDPrYnE=; b=NuRoNEMSHcmEor1KcoTr4QdkUioSIofuJLrU6v9VEvTEQZdIj0+kiGZoXDNez0WM50 Her3CqdBQzdkbpi2Y2ZTt0xdVJoGZrzspdezoVXLe3axug46N3gQ53eiRM/w5PbiD9K1 KC9V1Nq/7o9+bwdyiaNkEBc0HVtYYLAvM7pe8R3xkR7doKcDR+SOb3nDobUt6+BuKi9u DOZwLRDWwlwZu1O3NBEwnQtEpjpt3USacHaD2AUtoZUZu/Qsrd5b+lfwt7S947MpvcyG wMQOcFIw4cRH+J45oZIh1hKSwTmjVo0EqdR5j2TqK3xY8Qijexz6Tp1uD4kmoYURjl8i gjZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6rnRoRb9RZQqFfsdskKGmWsN8KJsse3lrdk8SDPrYnE=; b=SKYPXjajQd1OL606pR7aMcYPazy5RehqTW4RVtaesg7aJWIlvqQQ0oHru0IGc290RC jILBprlHzSm/Tp/BsCtKPtPL6+V1L8iNo4XF8+Ju4Y3c5h32KWy1EDxxQfJIV2Zpxe4u 6gsiofMxykJKeCGW5dRdgDedZuyqIOdK8UoIIN+1FxpmvoiV1e68wY/I6e2bnfnjyMyC PK/XQwWexWg6gsCdA63X8KPW6GCejfLTCK9Ae0Je0lKzjgSJVWwJ09teY3m8JyX5nCw+ W4O/StHpNoZEhLRFj/eJA29wAO0Z+rlTZ3LehqfxLnRW6WKLal0zaM12t16y9Ye0l/MV DLbw== X-Gm-Message-State: AGi0PuZoAyZOMlMhMCheLtnJ83fJuiM+S7UyCJnjjEVKQdzO5hHdxDdY Xeo7vKpFu5sgGYAtUy61koHUnd0OUE/0X5hDfZA= X-Google-Smtp-Source: APiQypKbFiMxMxHOx8IlrN6NYVv2rBjXXu9MMWTVKc0QSYwCMEM7cF3LSjAVoKpEWT5msVNKAKdrWG5P/gZF+U5fCmQ= X-Received: by 2002:a9d:1408:: with SMTP id h8mr14683386oth.174.1587928962184; Sun, 26 Apr 2020 12:22:42 -0700 (PDT) MIME-Version: 1.0 References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> In-Reply-To: From: Philipp Stephani Date: Sun, 26 Apr 2020 21:22:30 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Am So., 26. Apr. 2020 um 20:58 Uhr schrieb Paul Eggert : > > On 4/26/20 7:03 AM, Dmitry Gutov wrote: > > g++ string_const.c++ > > Ah, my example was C-only. Here is an example for both C and C++: > > #include > int main (void) { > union { char const *cp; char *p; } u = { "a" }; > return !strcpy (u.p, "b"); > } > > This has undefined behavior, and might dump core or might not depending on the > implementation. Neither gcc nor g++ issue any warnings in default compilation. Yes, but nobody "accidentally" writes code like this. OTOH, code like attempting to mutate a "constant" Lisp object seems trivial to write accidentally. > > Undefined behavior is undesirable and it's not a good thing that Emacs Lisp also > has areas that behave like this. Somebody should pry free time to look into > fixing them, but that won't be trivial. What would be needed? We could either (a) remove the notion of "constant" objects so that all objects become mutable, (b) introduce static type checking including const-correctness so that attempting to mutate a "constant" object would fail byte-compilation, and/or (c) make it an error to mutate such objects at runtime (similar to (set t nil)). From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 20:15: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 To: Philipp Stephani Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158793208519715 (code B ref 40671); Sun, 26 Apr 2020 20:15:01 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 20:14:45 +0000 Received: from localhost ([127.0.0.1]:35010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSnfp-00057v-1U for submit@debbugs.gnu.org; Sun, 26 Apr 2020 16:14:45 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSnfn-00057j-Br for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 16:14:43 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D1A4C16008D; Sun, 26 Apr 2020 13:14:37 -0700 (PDT) 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 cba1wifZvFWq; Sun, 26 Apr 2020 13:14:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0FED31600D1; Sun, 26 Apr 2020 13:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 5j_rfUnIO6rl; Sun, 26 Apr 2020 13:14:36 -0700 (PDT) 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 B179816008D; Sun, 26 Apr 2020 13:14:36 -0700 (PDT) References: <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <7631939e-d045-1dd6-f0f4-99caf9446739@cs.ucla.edu> Date: Sun, 26 Apr 2020 13:14:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/26/20 12:22 PM, Philipp Stephani wrote: > nobody "accidentally" writes code like this. Not code like my trivial example, no. But the underlying problem is all too common. After all, it's why Emacs is dumping core here - the Emacs Lisp interpreter is using C code like that to implement some Lisp strings. > We could either (a) remove the notion of > "constant" objects so that all objects become mutable, (b) introduce > static type checking including const-correctness so that attempting to > mutate a "constant" object would fail byte-compilation, and/or (c) > make it an error to mutate such objects at runtime (similar to (set t > nil)). Neither (a) nor (b) sound very practical. Emacs formerly did a better job at (c) and could do so again, so it's an obvious way to move forward here. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 21:24: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15879362362145 (code B ref 40671); Sun, 26 Apr 2020 21:24:02 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 21:23:56 +0000 Received: from localhost ([127.0.0.1]:35121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSokl-0000YX-Lq for submit@debbugs.gnu.org; Sun, 26 Apr 2020 17:23:55 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:33814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSokj-0000YH-Ql for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 17:23:54 -0400 Received: by mail-wm1-f49.google.com with SMTP id v4so14483980wme.1 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 14:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=R4FhbKunkKU875SUkimkRIzvuqBQRehmsTx8gM4Du0w=; b=NDPiIGu7iHjaN1Dky9NFWNz58RVh5i9G4MuT6P1GkoKiW5wYlnrScQlESJqnK6KS4O RIzmetdBmSjLSwUmY/5I4NU9+Y/7I3OMPbQDkbM/B/mOIVHGaQ4HrLoU/30J/4aHwlU1 g7JMkC6Zp8eqYSsmdi3/EUnTxQSsnMeHR2i6hga9H14EngI63Y/GBRWG1KJPxCUn/rLD xyLVog26eCiajSfqVlsa65JzYNZgLfjvywZD6ylYIOpx68RflpJRRo4zTaEthr56XdS2 UGmI3Pf0EpKGklEyJKGeJ5dHSqB7SWBELV8blqXrDRdpvOXPkroZSDyKcP1IF67S4wHH 4gJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=R4FhbKunkKU875SUkimkRIzvuqBQRehmsTx8gM4Du0w=; b=KgPXWTmDt6Kd2esJgY2X/+zLz/sayE6OQuSbw5ZOV4McaKNG/KHj1UjqHh9OWhZXCY MsCz13JkZeRdXjN0U4GVHc4InSiEq+Q1njhJ9XDVJoOrRAjWMhf1Z+CK2IiHzR4137ce Mj+qx7xhYj6ENbXkDrWTv7M4wmk4glCMeZwU78CvTKb7XpjTrD/msIufNbWcvT7XUpfB hzZsx5lKylCaakF07PkoUPl5WbkiSXNKVO1b2VdWNbIYEiEVF3WR5xK1+mVI8+6U80Ec 6WpYba+42JMjHO5rzRaF4Aerxdv2pFeiAoLKXkKdExSG5HkrMUtUXWMDHMS4qDdW7RMJ lBSQ== X-Gm-Message-State: AGi0PuaBuyCWUddbnJsN5dvs36MvMORRyrHlrzmHE490JH40xexhOjWl geZoXtYXoeKUZAKEL/k0gT8= X-Google-Smtp-Source: APiQypKyYq6AYVwYZvyFj2BAkYaxPXtycAyvpCyGpfbBprqvpXx43MtmJTM6j1fTjG2KbB20mjTI7Q== X-Received: by 2002:a1c:9a16:: with SMTP id c22mr21841669wme.38.1587936227880; Sun, 26 Apr 2020 14:23:47 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id o28sm18338896wra.84.2020.04.26.14.23.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 14:23:47 -0700 (PDT) References: <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> From: Dmitry Gutov Message-ID: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> Date: Mon, 27 Apr 2020 00:23:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 26.04.2020 21:57, Paul Eggert wrote: > On 4/26/20 7:03 AM, Dmitry Gutov wrote: >> g++ string_const.c++ > > Ah, my example was C-only. Here is an example for both C and C++: > > #include > int main (void) { > union { char const *cp; char *p; } u = { "a" }; > return !strcpy (u.p, "b"); > } > > This has undefined behavior, and might dump core or might not depending on the > implementation. Neither gcc nor g++ issue any warnings in default compilation. This just illustrates a weakness of type system in C/C++. The same way you could pass a string into a function that expects an int. > Undefined behavior is undesirable and it's not a good thing that Emacs Lisp also > has areas that behave like this. But is it undefined? I think it's well-defined and predictable, though it's harder to make sense of that we would like. > Somebody should pry free time to look into > fixing them, but that won't be trivial. It appears that portable dumping and > other changes have broken some of Emacs's runtime checking in this area. Do you have an example of a version of Emacs where this behavior was different? > Unfortunately, the relevant code is hairy and any fixes certainly won't happen > before the Emacs 27 release. In the meantime it's better to warn users clearly > about the gotchas in this area, to help prevent some of the confusion > exemplified by Bug#40671. Perhaps you meant some other bug report? This is the one we're commenting on. My concern here is the terms. I worry that someday someone will come report a problem, and we respond with "this syntax creates constant values, please take care not to modify them". Then that someone will go away with very low opinion of our mental faculties. In all of my experience, the term "constant" is usually applied to names (variables), or pointers. And it almost always means that you're not allowed to change it. Or if you are, you can't do it by accident. The closest term that applies to values, I think, is "immutable". But those are definitely protected from modification. For our situation, the term "constant reference" comes to mind, but I don't know exactly how to rephrase the manual best. The previous term "literal objects", however, seems accurate enough, and if the "constant-ness" is going to live only in the manual anyway, perhaps we should just say "please don't modify literal objects [unless you really know what you're doing]". From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 23:15: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158794284313676 (code B ref 40671); Sun, 26 Apr 2020 23:15:01 +0000 Received: (at 40671) by debbugs.gnu.org; 26 Apr 2020 23:14:03 +0000 Received: from localhost ([127.0.0.1]:35189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSqTL-0003YV-0G for submit@debbugs.gnu.org; Sun, 26 Apr 2020 19:14:03 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSqTI-0003Xp-UN for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 19:14:01 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 09E5A16008E; Sun, 26 Apr 2020 16:13:55 -0700 (PDT) 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 30DjwFFSZl_s; Sun, 26 Apr 2020 16:13:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2741A1600D3; Sun, 26 Apr 2020 16:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 7oHD7aij4f5V; Sun, 26 Apr 2020 16:13:54 -0700 (PDT) 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 CAE7016008E; Sun, 26 Apr 2020 16:13:53 -0700 (PDT) References: <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> Date: Sun, 26 Apr 2020 16:13:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/26/20 2:23 PM, Dmitry Gutov wrote: > This just illustrates a weakness of type system in C/C++. The same way you could > pass a string into a function that expects an int. Although it's a weakness, it's different from the char * vs int weakness. It's well-defined in C that one can cast char * to char const * and back without trouble. The same is not true for casting char * to int and back. > is it undefined? Yes, it's undefined. C11 section 6.7.3 paragraph 6 says, "If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined." > Do you have an example of a version of Emacs where this behavior was different? Emacs 26. >> Unfortunately, the relevant code is hairy and any fixes certainly won't happen >> before the Emacs 27 release. In the meantime it's better to warn users clearly >> about the gotchas in this area, to help prevent some of the confusion >> exemplified by Bug#40671. > > Perhaps you meant some other bug report? No, the original bug report that started this thread illustrates some of the confusion in this area. > In all of my experience, the term "constant" is usually applied to names > (variables), or pointers. And it almost always means that you're not allowed to > change it. Or if you are, you can't do it by accident. Unfortunately that experience does not apply to C and to other low-level languages. Even Java once allowed programs to modify "constants" by using reflection, though recent Java versions have fixed this. > The previous term "literal objects", however, seems accurate enough We could use any term we like, and if there's consensus for using the term "literal object" instead of "constant" then we can redo the manual that way. However, the problem can occur with strings that were never string literals in any source-code Elisp program. And a Elisp string can begin its life as a mutable string and then become a "constant" (or "literal object") later. So it's not clear that the longer phrase is less confusing. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2020 00:55: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158794884222673 (code B ref 40671); Mon, 27 Apr 2020 00:55:01 +0000 Received: (at 40671) by debbugs.gnu.org; 27 Apr 2020 00:54:02 +0000 Received: from localhost ([127.0.0.1]:35247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSs26-0005td-Ar for submit@debbugs.gnu.org; Sun, 26 Apr 2020 20:54:02 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:46767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSs24-0005t9-6J for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 20:54:00 -0400 Received: by mail-wr1-f42.google.com with SMTP id f13so18501483wrm.13 for <40671@debbugs.gnu.org>; Sun, 26 Apr 2020 17:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uJ5A03RahimetOFrSySQvXvhtKa7SYkqPm06eGl++0M=; b=cu67ZXSCm/XuLTE1USm2q/06e4rvdGo5T7Ewzu6jX+nZNnVN+it4IsBxrvXKT5DlQi Gg3CLoswP8894mmcVOVOoycoyTdwrf+WXBkxwhOWqZaKcGhnDVimsLWDm9hrygW0cJvT tytuvJwHePCXudBk/QdCrL4KsQ6TOku0hWYi2kQ2g1R3K0bH2iaMm2akV1tN6FKTk7N8 ZWi512OulHyLxttpakg7Uu3PcLDvc2K2okp4OmxCTlSj+uiMyFLUzboh0SNSjlazc2jj jzhN1/iVmQqGaM7oIKgxqawuoJOYuYKKetHv5dtZTAUKrowLHBL+LTRhdpmTmWPSITuL Mspg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uJ5A03RahimetOFrSySQvXvhtKa7SYkqPm06eGl++0M=; b=AOoJbhmKL9TGUAMYRguY9Ft7C4Pssa+AND0nxNLceUrns2PDuTvp94kQ1wrHO3t5b7 o0DuupeBbcKjolzknGJJOkfPd82BKWawoBlpz2U8j2poDdCUuY8YFVdQEDa9uwEOqjrV qZQRn1UTZs4BC6g7B1idDwKm05CubWk2lI98ci5pJi98TdmVZy/bt4iWbNyXzCH+8gEf GtDZhilCODREXVHKC/HPALKHNIUWCjH9pCZNdCXYnJpeGTVkclEh8ny1+BOh833zrSxx gl78xpkoKsIDNKDMqMEbOf8K5Gg7xWZbqmEiTrPCN0GUBkNhhESlUMpPp526xN/fSEGq yqYw== X-Gm-Message-State: AGi0PuafhfvHp8R3mO7HnIvxDej0we8iUBBrr7vl5tAmxjZLBC7lwYPh 1/ukHGVVgtdp/m3zlT5f8tU= X-Google-Smtp-Source: APiQypK/QQZB1qc8H85v202ATpexanFcvnjud4PDBLDTtTQL2kYb9I+qyXQp8PGU/NkYwobcQYJRsQ== X-Received: by 2002:a5d:4e12:: with SMTP id p18mr24969890wrt.148.1587948834238; Sun, 26 Apr 2020 17:53:54 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id q187sm13495940wma.41.2020.04.26.17.53.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 17:53:53 -0700 (PDT) References: <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> From: Dmitry Gutov Message-ID: <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> Date: Mon, 27 Apr 2020 03:53:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 27.04.2020 02:13, Paul Eggert wrote: >> This just illustrates a weakness of type system in C/C++. The same way you could >> pass a string into a function that expects an int. > > Although it's a weakness, it's different from the char * vs int weakness. It's > well-defined in C that one can cast char * to char const * and back without > trouble. The same is not true for casting char * to int and back. This compiles fine: #include int main (void) { return !strcpy ((char*)2, "b"); } My point is, it's hard to discuss static typing guarantees when type casting is involved. >> is it undefined? > > Yes, it's undefined. C11 section 6.7.3 paragraph 6 says, "If an attempt is made > to modify an object defined with a const-qualified type through use of an lvalue > with non-const-qualified type, the behavior is undefined." Sorry if that was unclear. I mean, is the behavior of "literal objects" in Emacs Lisp undefined when one tries to modify them? >> Do you have an example of a version of Emacs where this behavior was different? > > Emacs 26. Sorry, I don't have an Emacs 26 at hand. Should 25 suffice? Just tried this in IELM: ELISP> (setq a '(1 . 2)) (1 . 2) ELISP> (setcdr a 3) 3 (#o3, #x3, ?\C-c) ELISP> a (1 . 3) ELISP> emacs-version "25.2.3" >>> Unfortunately, the relevant code is hairy and any fixes certainly won't happen >>> before the Emacs 27 release. In the meantime it's better to warn users clearly >>> about the gotchas in this area, to help prevent some of the confusion >>> exemplified by Bug#40671. >> >> Perhaps you meant some other bug report? > > No, the original bug report that started this thread illustrates some of the > confusion in this area. Okay, yes. I though you had a bug report with a description of a practical problem. >> In all of my experience, the term "constant" is usually applied to names >> (variables), or pointers. And it almost always means that you're not allowed to >> change it. Or if you are, you can't do it by accident. > > Unfortunately that experience does not apply to C and to other low-level > languages. Even Java once allowed programs to modify "constants" by using > reflection, though recent Java versions have fixed this. Hence the last sentence of my paragraph you quoted. In Ruby, we also have "constants" and we sometimes laugh about being able to change them. And yet, there also you can't do it by accident. >> The previous term "literal objects", however, seems accurate enough > > We could use any term we like, and if there's consensus for using the term > "literal object" instead of "constant" then we can redo the manual that way. > However, the problem can occur with strings that were never string literals in > any source-code Elisp program. And a Elisp string can begin its life as a > mutable string and then become a "constant" (or "literal object") later. So it's > not clear that the longer phrase is less confusing. "A mutable string can become a constant later and yet remain modifiable in practice" sounds really confusing. We better warn against modifying any values that are part of a "literal object" anywhere. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2020 01:50: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158795217427800 (code B ref 40671); Mon, 27 Apr 2020 01:50:02 +0000 Received: (at 40671) by debbugs.gnu.org; 27 Apr 2020 01:49:34 +0000 Received: from localhost ([127.0.0.1]:35263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSstp-0007EJ-LA for submit@debbugs.gnu.org; Sun, 26 Apr 2020 21:49:33 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSstn-0007E4-4r for 40671@debbugs.gnu.org; Sun, 26 Apr 2020 21:49:31 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6852A16008E; Sun, 26 Apr 2020 18:49:24 -0700 (PDT) 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 gG3iJ2wBe-YH; Sun, 26 Apr 2020 18:49:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9BA521600D1; Sun, 26 Apr 2020 18:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 sfjMD31wKV_V; Sun, 26 Apr 2020 18:49:23 -0700 (PDT) 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 5F35F16008E; Sun, 26 Apr 2020 18:49:23 -0700 (PDT) References: <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> Date: Sun, 26 Apr 2020 18:49:23 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/26/20 5:53 PM, Dmitry Gutov wrote: > is the behavior of "literal objects" in Emacs > Lisp undefined when one tries to modify them? Yes. >>> Do you have an example of a version of Emacs where this behavior was different? >> >> Emacs 26. > > Sorry, I don't have an Emacs 26 at hand. Should 25 suffice? Yes. Just tried this in > IELM: > > ELISP> (setq a '(1 . 2)) > (1 . 2) > > ELISP> (setcdr a 3) > 3 (#o3, #x3, ?\C-c) > ELISP> a > (1 . 3) Yes, the behavior is undefined in Emacs 25 too. Undefined means that the behavior you describe is allowed - in this instance you modified the "constant" and got away with it. > In Ruby, we also have "constants" and we sometimes laugh about being able to > change them. And yet, there also you can't do it by accident. I suppose it depends on what one means by "accident". :-) Perhaps we could agree that accidents, whatever they are, happen more often in C.... > We better warn against modifying any values that are part of a "literal object" > anywhere. That's what the emacs-27 doc does, or at least tries to do. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 03:06: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158804313330242 (code B ref 40671); Tue, 28 Apr 2020 03:06:01 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 03:05:33 +0000 Received: from localhost ([127.0.0.1]:38549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTGYv-0007rg-BF for submit@debbugs.gnu.org; Mon, 27 Apr 2020 23:05:33 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:34998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTGYs-0007rT-82 for 40671@debbugs.gnu.org; Mon, 27 Apr 2020 23:05:30 -0400 Received: by mail-wr1-f43.google.com with SMTP id x18so22840791wrq.2 for <40671@debbugs.gnu.org>; Mon, 27 Apr 2020 20:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sSXphqRCN/jFormBv0QxDEfTM1SvaYtnQkGCFIOVtOY=; b=QbYohH9AdDj73ILYh5XM/5oAzwEEqYJkaCkNWtHV6NNd/MatmxFCjWGIOBnliu6ILM vXisynl8nXskFvfET312WTjhKn8hodZ8XmeMJ54/3TwTuQqR7HTmhq9pqA5MRfgbFMdE MNGgZooKccB9TuVmBBp8/uB+P5EEa0yqTxE6GsnE3oMUnQYgSSq6moM68yr1WHK+Xg/s /rm5P+X0exw0ypBMItdgGlMgi1U0N1xMS/ahzDtjjSXrVWF5LP6TaJsM5TAtTDORAHBb DEQZ8ImRfOt66o7gEJecBKCf4QG4s7/UDlODjd6TNEgzLN/FN4+gu+pkQyMIliosTszg bqUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sSXphqRCN/jFormBv0QxDEfTM1SvaYtnQkGCFIOVtOY=; b=cUne+Jl99K+9GsYaSpTptUa0L6u4M9JZp9ePtZOyxqJ89dEWztVAPuVPVzxQ5tXiUn sQyCiTGyhz37bEt2lOSKOuHD1d1DmDnPLCLXAS/nYZnI/NPCKHcoOYtgGSnzyquwOa8m uI/7igYo4EyZYeE02ZJ51OSRgamwbnzSNMH29QeBbY9sJg/OnzNU3k85G/udwH5Zqtih 9rtlPfZkPD3n7Ax/th4E3q1Z35MB4JhKena2bAgzawQHFYmQXblDC92rHWthvknkeJ9R XQ5K6ad1vuHkknc/2LLv+0buhqbw38TwmDa+6aKtymG2bU+2uidQmsu8Stzw2uTso40N 77/A== X-Gm-Message-State: AGi0PubYmHB0Dix+avzKfssu2bNT3pqJc6ADlVtD3EUGxhNBlRSw1R07 hP+f5t1dBL3eLk5ePfjOYgg= X-Google-Smtp-Source: APiQypKhRPKQv1lxYMrrUHTldaDxn20YBzvzJMRptngiBiKy3WcaA3znhy2JRmSmxii2N515rUA7yQ== X-Received: by 2002:a5d:6503:: with SMTP id x3mr33675968wru.153.1588043124247; Mon, 27 Apr 2020 20:05:24 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id h5sm24147160wrp.97.2020.04.27.20.05.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Apr 2020 20:05:23 -0700 (PDT) References: <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> From: Dmitry Gutov Message-ID: <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> Date: Tue, 28 Apr 2020 06:05:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 27.04.2020 04:49, Paul Eggert wrote: >> Sorry, I don't have an Emacs 26 at hand. Should 25 suffice? > > Yes. > > Just tried this in >> IELM: >> >> ELISP> (setq a '(1 . 2)) >> (1 . 2) >> >> ELISP> (setcdr a 3) >> 3 (#o3, #x3, ?\C-c) >> ELISP> a >> (1 . 3) > > Yes, the behavior is undefined in Emacs 25 too. Undefined means that the > behavior you describe is allowed - in this instance you modified the "constant" > and got away with it. I'm not sure which problematic cases you mean, then. Ones related to pure space? >> In Ruby, we also have "constants" and we sometimes laugh about being able to >> change them. And yet, there also you can't do it by accident. > > I suppose it depends on what one means by "accident". :-) Perhaps we could agree > that accidents, whatever they are, happen more often in C.... It feels like you're just side-stepping the arguments, one after another. >> We better warn against modifying any values that are part of a "literal object" >> anywhere. > > That's what the emacs-27 doc does, or at least tries to do. I wish it did that without inventing new meanings for the words "constant" and "mutable". It will only breed confusion. Take this paragraph: Although all numbers are constants and all markers are mutable, some types contain both constant and mutable members. These types include conses, vectors, strings, and symbols. For example, the string literal @code{"aaa"} yields a constant string, whereas the function call @code{(make-string 3 ?a)} yields a mutable string that can be changed via later calls to @code{aset}. It makes one think that 'aset' can't be called on "aaa". That it will either fail to change the value, or signal an error. Whereas the result is that the value is changed, no errors or warnings. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 08:18: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158806187929229 (code B ref 40671); Tue, 28 Apr 2020 08:18:01 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 08:17:59 +0000 Received: from localhost ([127.0.0.1]:38799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTLRG-0007bN-Uz for submit@debbugs.gnu.org; Tue, 28 Apr 2020 04:17:59 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:46620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTLRB-0007b5-7c for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 04:17:57 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BCA21160052; Tue, 28 Apr 2020 01:17:47 -0700 (PDT) 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 ZRsU-SqJ8a8I; Tue, 28 Apr 2020 01:17:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E77B516008E; Tue, 28 Apr 2020 01:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 mXEGtX9Gc7hB; Tue, 28 Apr 2020 01:17:46 -0700 (PDT) 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 B110D160052; Tue, 28 Apr 2020 01:17:46 -0700 (PDT) References: <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> Date: Tue, 28 Apr 2020 01:17:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/27/20 8:05 PM, Dmitry Gutov wrote: > I'm not sure which problematic cases you mean, then. Ones related to pu= re space? That's one issue. Earlier versions of Emacs also had trouble if you modif= ied list structures while executing them. I've squashed some of those issues = more recently but would not be surprised if some remain. I don't know how much optimization the byte compiler did in earlier versi= ons, but if it did anything like what it does now, that's also a source of pro= blems. > =C2=A0=C2=A0=C2=A0 Although all numbers are constants and all markers a= re > =C2=A0 mutable, some types contain both constant and mutable members.=C2= =A0 These > =C2=A0 types include conses, vectors, strings, and symbols.=C2=A0 For e= xample, the > =C2=A0 string > =C2=A0 literal @code{"aaa"} yields a constant string, whereas the funct= ion > =C2=A0 call @code{(make-string 3 ?a)} yields a mutable string that can = be > =C2=A0 changed via later calls to @code{aset}. >=20 > It makes one think that 'aset' can't be called on "aaa". That it will e= ither > fail to change the value, or signal an error. Whereas the result is tha= t the > value is changed, no errors or warnings. 'aset' *shouldn't* be called on "aaa". We could replace "a constant string" with "a constant string that should = not be changed"; would that help? > It feels like you're just side-stepping the arguments, one after anothe= r.=20 There's certainly no intent to side-step. And I don't sense that there's = really much disagreement here: we both agree that the current behavior is unfort= unate, the major point of disagreement is about terminology in the documentation= . From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 13:55: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15880820985057 (code B ref 40671); Tue, 28 Apr 2020 13:55:02 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 13:54:58 +0000 Received: from localhost ([127.0.0.1]:39366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTQhO-0001JV-4C for submit@debbugs.gnu.org; Tue, 28 Apr 2020 09:54:58 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:36685) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTQhK-0001J3-Mo for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 09:54:57 -0400 Received: by mail-wm1-f46.google.com with SMTP id u127so2970004wmg.1 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 06:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IYzdIbCHyG7hwkEbF/v0BzdTN1c4MJ0j+DECzaNF948=; b=Mgm4A4CceBP6kZipI+0QoWEyrSoPSaAcOb4u1Of/UiFzwcwozFLnwLimwQPVFvlOuP A+hyKdLcWJTZ79O7qpRbP6jk1G8EmW2wP83tXlmtQZOuJf+uUhk56SpPujlVyoCSWko5 6jmkbLOdX5Vv2L4NyX/6ly46sS27bKTT4lkuVOoIc7bKh8uouZ18mkJ593Zt4VCPnHsf bcz9xtEJTxZJ4R7t0EQlHycG7e1xWK5sS+rrnXuIbF3+3INMwM0diZg3sp42OwQwrMEB zugdVJaSXEGmOR1RzFXo0rexOmHAoHvDB1QyLyIXAhylAKXrPx6sSMrpJec1cbuKYvuJ GDSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IYzdIbCHyG7hwkEbF/v0BzdTN1c4MJ0j+DECzaNF948=; b=M+uyHSp10Towj8UjfkMM+rTRTUSwKdH8Hj2+NMiyNCgJ5nUt1ZVfQDapl5CVGpwBgY vX+Ku5M5rgHy1yvsjAVCMaSqOYrviD2wVtOBRDcUbtHbZX0ehoWk0WsC8/TtIbYJOpoU GKdlheiL+mNMrPmko05/F6gaF3nvlVLyuhLHmCSraA9UuHkqdweIG6poSd74MP0CYMYS WE39+CWxroJzdDRi6+FDth7PcQ+dyQLWjOiHTqC3KargK6iZKPyEfGD6uLpXCGqgU22n Sr7GgwJn9pFT3CFPFLgbvyMKz5BO4s/YFeiZZ/MPeAL9bIkxSLikeuv/5zPaO90pKVZR IKXA== X-Gm-Message-State: AGi0PubdDh5qfIn0UcngL5qGAJhYOdaokQxcCyjQP43m3rX+CVGuZDAv Vqbl63eQ4dS6oNviUwp8Ofo= X-Google-Smtp-Source: APiQypLzr+bvqKUagyQ3M87qTOHsdYDBZ3UuwnFka715OtexRWp1NDnjNcvX84As46nukb8EK/yfvw== X-Received: by 2002:a05:600c:4102:: with SMTP id j2mr5042858wmi.159.1588082088580; Tue, 28 Apr 2020 06:54:48 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id r3sm26691111wrx.72.2020.04.28.06.54.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 06:54:47 -0700 (PDT) References: <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> From: Dmitry Gutov Message-ID: <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> Date: Tue, 28 Apr 2020 16:54:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 28.04.2020 11:17, Paul Eggert wrote: > On 4/27/20 8:05 PM, Dmitry Gutov wrote: > >> I'm not sure which problematic cases you mean, then. Ones related to pure space? > > That's one issue. Earlier versions of Emacs also had trouble if you modified > list structures while executing them. I've squashed some of those issues more > recently but would not be surprised if some remain. If any led to segfaults, they have to be fixed in the code anyway. > I don't know how much optimization the byte compiler did in earlier versions, > but if it did anything like what it does now, that's also a source of problems. Well, here's a damning example. And it doesn't involve the byte compiler: ELISP> (defun abc () "abc") abc ELISP> (aset (abc) 0 ?b) 98 (#o142, #x62, ?b) ELISP> (abc) "bbc" I wonder how other Lisps deal with that. The Ruby interpreter, from the first release I think, always created copies of the literals when a method was called. Exactly to avoid this kind of broken semantics. In the recent versions, they added a pragma string (to be added to the top of the file) that makes all such literals in that file "immutable". That means that any attempt to change them errors at runtime. And now it's considered good style to use that pragma everywhere. >>     Although all numbers are constants and all markers are >>   mutable, some types contain both constant and mutable members.  These >>   types include conses, vectors, strings, and symbols.  For example, the >>   string >>   literal @code{"aaa"} yields a constant string, whereas the function >>   call @code{(make-string 3 ?a)} yields a mutable string that can be >>   changed via later calls to @code{aset}. >> >> It makes one think that 'aset' can't be called on "aaa". That it will either >> fail to change the value, or signal an error. Whereas the result is that the >> value is changed, no errors or warnings. > > 'aset' *shouldn't* be called on "aaa". Indeed it shouldn't. > We could replace "a constant string" with "a constant string that should not be > changed"; would that help? That sounds like a weird tautological non-advice. It shouldn't be changed because it's a value of a string literal. Not because it's constant (it isn't). >> It feels like you're just side-stepping the arguments, one after another. > > There's certainly no intent to side-step. And I don't sense that there's really > much disagreement here: we both agree that the current behavior is unfortunate, > the major point of disagreement is about terminology in the documentation. From the outset all arguments were about the terminology. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 17:26: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 To: Paul Eggert , Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158809475727135 (code B ref 40671); Tue, 28 Apr 2020 17:26:02 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 17:25:57 +0000 Received: from localhost ([127.0.0.1]:41279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTTzY-00073a-VN for submit@debbugs.gnu.org; Tue, 28 Apr 2020 13:25:57 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:52296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTTzX-00073N-Dx for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 13:25:55 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03SHNCli129494; Tue, 28 Apr 2020 17:25:40 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=RbW+DmmH0uYovUngYCmpJ36TW+weJ/qYK6SAyFbO//8=; b=iOJF0A4uGgGPPrDob5y8uzk0b0G1c9NR4I6sjZZAoVHeUYcPIJEDbv+td3fm1Tp5o6vL D/tP5VTuw6ct46k1liWHA2Pe8Uy4o/clXKMV9VHNIR26I1sz+shlYvzl5Sw+nklda2B+ Wk0dpI57t3Sewxb7/swrh08IG4TYBz5Ugvdkof1/24BWZWkPCkRkt22Wqpvb+6gaPWve ixtdUb93cS6FrZsww9OA4WPcAdRbbjTEwoh3xhZ2CUbnrEPWpvpDuTbQ+F6iksPOqAUv j4TuODGenPu4NLifG7S2kjwaObOFHKivGGVh9ajGnMmDExbyUzXaQO/emg4mfnQmvSg2 Ew== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 30p01nqvsa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Apr 2020 17:25:40 +0000 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 03SHM4eG028437; Tue, 28 Apr 2020 17:25:39 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 30mxrt1fsh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Apr 2020 17:25:39 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03SHPXFp029185; Tue, 28 Apr 2020 17:25:33 GMT MIME-Version: 1.0 Message-ID: <1080866d-778f-493e-9c51-3893eeaf7203@default> Date: Tue, 28 Apr 2020 10:25:32 -0700 (PDT) From: Drew Adams References: <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> In-Reply-To: <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 suspectscore=18 mlxlogscore=848 malwarescore=0 bulkscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004280137 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 clxscore=1015 phishscore=0 mlxlogscore=893 adultscore=0 priorityscore=1501 mlxscore=0 suspectscore=18 malwarescore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004280137 X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) > There's certainly no intent to side-step. > And I don't sense that there's really > much disagreement here: we both agree that > the current behavior is unfortunate, > the major point of disagreement is about > terminology in the documentation. Has anyone agreed with you here about your use of "cannot" instead of "should not" and your unconventional use of "constant"/"immutable" and "mutable"? I don't think I've seen any support for that here (did I just miss it?). Still you persist. I don't really see the doc/message for users getting clearer; it seems like the waters are being muddied. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 17:48: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 To: Drew Adams , Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15880960715117 (code B ref 40671); Tue, 28 Apr 2020 17:48:02 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 17:47:51 +0000 Received: from localhost ([127.0.0.1]:41387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTUKl-0001KT-CC for submit@debbugs.gnu.org; Tue, 28 Apr 2020 13:47:51 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTUKj-0001KF-D2 for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 13:47:50 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A59E816008E; Tue, 28 Apr 2020 10:47:43 -0700 (PDT) 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 MHY3lGtUGo_A; Tue, 28 Apr 2020 10:47:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F0E96160094; Tue, 28 Apr 2020 10:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 YoxVlb1cfnHR; Tue, 28 Apr 2020 10:47:42 -0700 (PDT) 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 A262416008E; Tue, 28 Apr 2020 10:47:42 -0700 (PDT) References: <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <1080866d-778f-493e-9c51-3893eeaf7203@default> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <3aa1e901-c74e-e2cb-f47f-99aa939f3821@cs.ucla.edu> Date: Tue, 28 Apr 2020 10:47:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1080866d-778f-493e-9c51-3893eeaf7203@default> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 10:25 AM, Drew Adams wrote: > Has anyone agreed with you Nobody's happy with the current documentation's language (not even me), but nobody has proposed specific wording improvements either. That's what committees do sometimes; we might not agree, but the guy who does most of the work generates something that nobody has the time to improve significantly. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 18:00: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15880967906263 (code B ref 40671); Tue, 28 Apr 2020 18:00:02 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 17:59:50 +0000 Received: from localhost ([127.0.0.1]:41400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTUWL-0001cx-M6 for submit@debbugs.gnu.org; Tue, 28 Apr 2020 13:59:49 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTUWJ-0001cf-NG for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 13:59:48 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 26167160094; Tue, 28 Apr 2020 10:59:42 -0700 (PDT) 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 GAcdED2NRl61; Tue, 28 Apr 2020 10:59:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5D0DB1600C3; Tue, 28 Apr 2020 10:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 mSERuixJN5j0; Tue, 28 Apr 2020 10:59:41 -0700 (PDT) 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 0864316008E; Tue, 28 Apr 2020 10:59:41 -0700 (PDT) References: <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> Date: Tue, 28 Apr 2020 10:59:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 6:54 AM, Dmitry Gutov wrote: > It shouldn't be changed because it's a value of a string literal. Not because > it's constant (it isn't). That depends on the string literal and the particular Emacs implementation. In Emacs master, some string literals yield strings that are constant because Emacs has undefined behavior at the C level (maybe coredump, maybe not) if you try to change them, some string literals are constant because if you try to change them Emacs will reliably signal an error, some string literals are constant because if you change them Emacs might behave unpredictably without having undefined behavior at the C level, and the remaining string literals are constant becase you shouldn't change them. We have never documented exactly which string literals are which, and we shouldn't document that now because it is an implementation detail that users should not rely upon. It would be a mistake for the documentation to say that the problems we've been discussing occur only with string literals, as these problems can occur for strings that were not generated from string literals, and they can also occur for objects that are not strings. So "string literal" would be the wrong terminology here. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 18:47: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158809958224003 (code B ref 40671); Tue, 28 Apr 2020 18:47:02 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 18:46:22 +0000 Received: from localhost ([127.0.0.1]:41478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTVFO-0006Ek-3Y for submit@debbugs.gnu.org; Tue, 28 Apr 2020 14:46:22 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:40994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTVFM-00068v-3D for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 14:46:20 -0400 Received: by mail-wr1-f49.google.com with SMTP id g13so25919421wrb.8 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 11:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HjuJUT8g/6bmK9qw1EUnh8AI28EcjB0XKbVjKwZOd2s=; b=IJR4nwgoV6/0VNWoPpiCdRMUYhTRvAbAmFux7weVh4LzGcUTBNJBtkJ/v9/Y626rhI MJjmboAa0U5PY51ymSfmlBOizUzNKvyvrig3tKJb7Pp4nMmObHQR+g3kLVMoysBG+NT7 h17tU2/Acnizc5hvit1E/LL2TgPJxhyLyu5ruhRp6XISmhy0xybWo2ObC8MQb2sfhstQ DRWk9r5lYEVbg5Q7+dyWjk7sr3IcrtaHFMm8vyud2dxFxqdx8AJj4rdkSxH60TryjHk/ wAdHZwESAGqFCbk167JGj+TRGN2d7J5+Sh5Rx02fM9QRsDKNGlSPePu6nqab2uR6Zi6A kj9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HjuJUT8g/6bmK9qw1EUnh8AI28EcjB0XKbVjKwZOd2s=; b=YsT4NmdcxvtutD+zZGwOtLbc+0QKCg5Z3dvK1/So+nNcHfryizYueb7GAGEvsnkEC1 gvAN7Vpo2A2ubtGtMgbR6OLD2g/CAmB/DCJqYXoXWcQUHBAIFi8RUAeQozOIYa9QI47b EWGBl3AfNH6BXnO8Y1wUVadIJK+KcjzUztmiXnPy1LIBBa/ahHZaQwFowIq6gzymzxdU 7OzJ6n+ARWPR9Iq0eTEXlqMPXLPQ3KnODalvQkjSsCtvVsGEc3GCeFP4nbiLFsYeMbft 3Q9UpgukuQuNIt/hL8EnGiNPdzt99SbeN32Shg+2NZ5lXvLIo2hP0uiCCjgS8RuOxbDM u+bA== X-Gm-Message-State: AGi0PuZfu34c4yIoJ9oHnUA/R9ltunGELAzBAP5axCAunWnKI4e4aEHA c6EjbfFzBN5P2OMp1ncESdY= X-Google-Smtp-Source: APiQypLmXfUbiITgJKz5zJitAYko8HmGhAflLoCO2nhCNb45+SKQ6EzmOQjYvBtts6h7OxQpY9H91A== X-Received: by 2002:a5d:688f:: with SMTP id h15mr35003526wru.352.1588099573926; Tue, 28 Apr 2020 11:46:13 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id x13sm4361368wmc.5.2020.04.28.11.46.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 11:46:13 -0700 (PDT) References: <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> From: Dmitry Gutov Message-ID: <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> Date: Tue, 28 Apr 2020 21:46:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 28.04.2020 20:59, Paul Eggert wrote: > On 4/28/20 6:54 AM, Dmitry Gutov wrote: >> It shouldn't be changed because it's a value of a string literal. Not because >> it's constant (it isn't). > > That depends on the string literal and the particular Emacs implementation. In > Emacs master, some string literals yield strings that are constant because Emacs > has undefined behavior at the C level (maybe coredump, maybe not) That sounds like something we have to fix. Emacs shouldn't dump core no matter what Lisp code the user wrote. Unless it leads to an OOM, I guess. > if you try to > change them, some string literals are constant because if you try to change them > Emacs will reliably signal an error, some string literals are constant because > if you change them Emacs might behave unpredictably without having undefined > behavior at the C level, and the remaining string literals are constant becase > you shouldn't change them. That's not a constant, that's an eldritch abomination. Some unknown, unpredictable thing. Which is generally bad for language semantics and for its users. I understand why it's hard to fix that, but co-opting common words to mean different things is bad. Using semantics that might be "slightly familiar" only to grizzled C programmers is also bad. If you really want to have an adjective for such values, either ask some language theorist or make up one (and I'm only half-kidding here). Example: Some values in Emacs are constant, meaning you can't change them (e.g. you can't change an integer), and some are mutable (e.g. a cons cell is easy to change). There is a particular kind of values called fizzleworp (see {String literals}, {Quote} and {Backquote}), which are dangerous to modify. Please take care not to do that in your code. <... some enumeration of situation which create fizzleworp values or make an existing value fizzleworp ...> OR Anyplace we introduce literals in the manual, if they are dangerous to modify, we say that. Without inventing new words. > We have never documented exactly which string > literals are which, and we shouldn't document that now because it is an > implementation detail that users should not rely upon. No argument here. > It would be a mistake for the documentation to say that the problems we've been > discussing occur only with string literals, as these problems can occur for > strings that were not generated from string literals, and they can also occur > for objects that are not strings. So "string literal" would be the wrong > terminology here. String literals, Lisp form literals, and any members of such forms. I might be forgetting something, but this list is not too long, is it? From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 19:21: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881016376196 (code B ref 40671); Tue, 28 Apr 2020 19:21:01 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 19:20:37 +0000 Received: from localhost ([127.0.0.1]:41555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTVmW-0001bs-Vi for submit@debbugs.gnu.org; Tue, 28 Apr 2020 15:20:37 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50158) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTVmP-0001bX-ST for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 15:20:35 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id ED61E1600C3; Tue, 28 Apr 2020 12:20:23 -0700 (PDT) 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 czstxuQKHbmR; Tue, 28 Apr 2020 12:20:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6B170160094; Tue, 28 Apr 2020 12:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 t8rFYayOh2Vi; Tue, 28 Apr 2020 12:20:22 -0700 (PDT) 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 2131416008E; Tue, 28 Apr 2020 12:20:22 -0700 (PDT) References: <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> Date: Tue, 28 Apr 2020 12:20:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 11:46 AM, Dmitry Gutov wrote: > That sounds like something we have to fix. Yes, absolutely, though we can't feasibly do that before the next release. > That's not a constant, that's an eldritch abomination. I say "constant", you say "eldritch". :-) > Using semantics that might be "slightly familiar" > only to grizzled C programmers is also bad. It's not just "slightly familiar" to grizzled C/C++/etc. programmers. It's a concept that's pretty much part of their daily lives. > There is a particular kind of values called fizzleworp (see {String literals}, {Quote} and {Backquote}), which are dangerous to modify. Let's not go that route. It'd be overdocumenting internal details that are not generally known. I don't know all the details, so I couldn't write all that documentation without a lot of nontrivial investigation. And these details are likely to change so users should not rely on them anyway. Instead of going out into the wilderness and tagging and identifying each dragon and its lair, the documentation should keep things simple and merely say "there are dragons out in the wilderness; you shouldn't go there". This is much simpler and easier to understand and maintain, and is safer overall. > Lisp form literals, and any members of such forms. I might be forgetting something, but this list is not too long, is it? Yes the list isn't *that* long, and it's in the documentation already - as long as we are willing to put up with a conservative list (e.g., you shouldn't modify anything in the list) rather than insisting on an exhaustive list (e.g., here's what happens if you try to modify X, here's what happens if you try to modify Y, etc.). From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 19:35: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881024417466 (code B ref 40671); Tue, 28 Apr 2020 19:35:01 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 19:34:01 +0000 Received: from localhost ([127.0.0.1]:41566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTVzV-0001wJ-8N for submit@debbugs.gnu.org; Tue, 28 Apr 2020 15:34:01 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:40182) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTVzT-0001w4-Lo for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 15:34:00 -0400 Received: by mail-wr1-f41.google.com with SMTP id k13so26125900wrw.7 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 12:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ayQC7BXoFE0+Zm9b9/MEpsxGhKEXvHwZKca7NEPlppU=; b=jgHjye6yE33GosjOHtKoCR5k9CD3ULiccTl0qS3j9i7j1cro4dvBaxZaGeds1MJ9X3 kFgTGkM9F7V+79eZlCg5JIwWfZ9/LPfX56TYOMflExQH4r+QcBEDbggtUXFPNcU+qz7o 0zy1S2AazvMB0+8KFPznWQEh826sRmPTdNGCkUgnfpsLdG6m3CYlDeKY90pkPD8i1u88 nSXVqwj6ROv8iLNlPJVOQgc6f9pfpNAsmd3/dUHtEMode9CIpVTjJslsHqzxiGKr7iie y1uAXAvCiSEWsw1H737VGt4ow470inzPJhZ5oSbxgWAbXderz45ICivgH9HAKb2okUIV 7kFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ayQC7BXoFE0+Zm9b9/MEpsxGhKEXvHwZKca7NEPlppU=; b=dTsUEC61N5JfEss7KCrkxzIxtkkExukt3X9OTVaAQNwyE3NhEuubSLn9D0zn3+1Xxf wLzNV0TqJ9cjLqn1uOZ3oU/AklWmxG3DH9QZoUoMGpSJtDJ9dogGwdtycodss/DOELQ3 Q149viPJQnm9i4PmgFWk7SxSmOHOTIwWmIx3eexYlw8qr0z2OE3vNamtYE69Md8APCGr XpkKLbrzzF8NRdcdb9jtgtn/34jOMmvpbqgTPqCpa6WK4s44RFrE7Gv6YbfWeLOC1spa XQ23iKpBQOKEI+3et+6AgepsnJsjcJe7q3fHWnep5cbpR2PxmrjaLxVfqugraRewwBvu JyiA== X-Gm-Message-State: AGi0PuY7Aw2cfS/FF5Bsg9Jie0F1Y5mq7YZg1UlRnAtfX4Z/JvRq5OW/ SJx96z7H2ySGdOg0L2hVzFY= X-Google-Smtp-Source: APiQypJBjfMmqSl/3FX+SDTuNUxgDhjnqDLBoB6n6vyArpWcA2yM1rJ8wDXTHutQcr223Vib4oRXKQ== X-Received: by 2002:a5d:4645:: with SMTP id j5mr33747501wrs.282.1588102433668; Tue, 28 Apr 2020 12:33:53 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id t16sm27336508wrb.8.2020.04.28.12.33.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 12:33:52 -0700 (PDT) References: <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> From: Dmitry Gutov Message-ID: <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> Date: Tue, 28 Apr 2020 22:33:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 28.04.2020 22:20, Paul Eggert wrote: > On 4/28/20 11:46 AM, Dmitry Gutov wrote: > >> That sounds like something we have to fix. > > Yes, absolutely, though we can't feasibly do that before the next release. Yeah, ok. >> That's not a constant, that's an eldritch abomination. > > I say "constant", you say "eldritch". :-) And then I explain why "constant" is bad, multiple times. With examples from other languages. >> Using semantics that might be "slightly familiar" >> only to grizzled C programmers is also bad. > > It's not just "slightly familiar" to grizzled C/C++/etc. programmers. It's a > concept that's pretty much part of their daily lives. You take the concept of "constant values", look it up in the C standard (where modifying a constant is "undefined behavior") and then make a conclusion that if modifying something is "undefined behavior", it must be called a constant. Outside of C standard, to boot. Emacs users are not C programmers. >> There is a particular kind of values called fizzleworp (see {String literals}, {Quote} and {Backquote}), which are dangerous to modify. > > Let's not go that route. It'd be overdocumenting internal details that are not > generally known. I don't know all the details, so I couldn't write all that > documentation without a lot of nontrivial investigation. And these details are > likely to change so users should not rely on them anyway. That's not what I was suggesting. I gave an example on using the words, not on which cases to enumerate. > Instead of going out into the wilderness and tagging and identifying each dragon > and its lair, the documentation should keep things simple and merely say "there > are dragons out in the wilderness; you shouldn't go there". This is much simpler > and easier to understand and maintain, and is safer overall. The map still has to circle the wilderness on the map somehow. >> Lisp form literals, and any members of such forms. I might be forgetting something, but this list is not too long, is it? > > Yes the list isn't *that* long, and it's in the documentation already - as long > as we are willing to put up with a conservative list (e.g., you shouldn't modify > anything in the list) rather than insisting on an exhaustive list (e.g., here's > what happens if you try to modify X, here's what happens if you try to modify Y, > etc.). Conservative list is fine, as long as we don't use the word "constant". From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 20:10: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158810455810859 (code B ref 40671); Tue, 28 Apr 2020 20:10:01 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 20:09:18 +0000 Received: from localhost ([127.0.0.1]:41630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTWXd-0002p5-Vh for submit@debbugs.gnu.org; Tue, 28 Apr 2020 16:09:18 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTWXb-0002os-DR for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 16:09:15 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E19D916008E; Tue, 28 Apr 2020 13:09:09 -0700 (PDT) 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 Hu3KCUaWu8Oi; Tue, 28 Apr 2020 13:09:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 049B7160094; Tue, 28 Apr 2020 13:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 XHJeEMAMRwKQ; Tue, 28 Apr 2020 13:09:08 -0700 (PDT) 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 A81B216008E; Tue, 28 Apr 2020 13:09:08 -0700 (PDT) References: <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Tue, 28 Apr 2020 13:09:08 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 12:33 PM, Dmitry Gutov wrote: > And then I explain why "constant" is bad, multiple times. With examples from > other languages. The word "constant" means different things in different programming languages. The meaning used in the Elisp manual is reasonably close to its meaning in C/C++/Fortran/Common Lisp/etc., and that describes how Emacs behaves now. We'd prefer it if Emacs behaved more like what Python does with its immutable objects, and some day we should change Emacs to do that. When we do so, we can modify the Elisp manual accordingly. In the meantime we need to document what we have. > Emacs users are not C programmers. Of course not, but this area needs documentation and when the Emacs concept is similar to an already-existing one in C/C++/etc. it's not necessarily a bad thing to adopt their terminology and/or notation, even if that terminology/notation happens to mean something else in other contexts. >>> There is a particular kind of values called fizzleworp (see {String >>> literals}, {Quote} and {Backquote}), which are dangerous to modify. >> >> Let's not go that route. It'd be overdocumenting internal details that are not >> generally known. I don't know all the details, so I couldn't write all that >> documentation without a lot of nontrivial investigation. And these details are >> likely to change so users should not rely on them anyway. > > That's not what I was suggesting. I gave an example on using the words, not on > which cases to enumerate. Then I don't understand your suggestion. I thought you were saying that we should distinguish among the types of constants and should say what happens when you modify each type. The manual already does this to a very limited extent, and I thought you were suggesting that it should do a reasonably exhaustive job of it, in order to greatly limit the area where Emacs behavior is undefined. I'd rather not go that route generally, for the reasons stated above. That being said, it might make sense to make some changes in this area. Or perhaps I'm still misunderstanding you, in which case further clarification would be helpful. A simple way to be clear in this area is to propose specific wording changes, preferably in git format-patch form. It's not enough to say "I don't like the word 'constant'." > The map still has to circle the wilderness on the map somehow. Yes, and the documentation does that now. The edge of the wild is the line between constants and non-constants. A program that tries to modify a constant is out in the wilderness. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 21:12: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158810826918153 (code B ref 40671); Tue, 28 Apr 2020 21:12:02 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 21:11:09 +0000 Received: from localhost ([127.0.0.1]:41773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTXVI-0004i2-A3 for submit@debbugs.gnu.org; Tue, 28 Apr 2020 17:11:09 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:41324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTXVH-0004hc-5E for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 17:10:55 -0400 Received: by mail-wr1-f43.google.com with SMTP id g13so26370892wrb.8 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 14:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NFZGPFk+l32hnVaWIoyJsQWOR6GhIFYfI6oDpoa6n2A=; b=aN1MQq0El5WHLihllWoddthEkn667Q96JBeqs0RkQgc3dtvgDiOULPldp1khdCmiUt u5dmYqxUg7blpUhIj2J3zrfTyacWF6kSBuzQp/7WL7jVdWBuGCYSAQajWhfWfXWnCGBU eWfXjAVDgNMeFzVGLPOX4VLBkpAjJwOajQSsbi0YjKjARXnlkyGIXv6wf9cx+hwa4KJF 11CLq4iU5Dxllrx5HcV/kRO2Y84pB/hiwIsbhjfrh9doTYMhYVTiGf8dtduzj7U95niv Tq+SuQpPbDdnK/E2qVZmtJKGWwBHgfeEfwi2pK+hk/0yetVqe1Rr+ElM2eigPHlqVggI gx3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NFZGPFk+l32hnVaWIoyJsQWOR6GhIFYfI6oDpoa6n2A=; b=XAJ5eS3JhAgalmvLjVoJn7v9hmVri+tUvLvXbhtx+YExZJhehp44LJ1+NB4RzSmWDM cxVAKlyO4BXWfU4emQmupefyBodUxMi9I7xG/5A/JFfKsmTkz5LLIL3a4x/nDu8rAu2n Vmbp3VQPJuQDt8uZgVtrvLzyetsxa1lkgLdyulYFm8rDs7zZtjEOgH+k9/LEL7FR0efE QaXe79YDp7tiqT+Pqp3vSkLw6D8GebO4jpcXt/WoddOex93dYSKPyUXxKo1WD0bS1FXF 6umnvL9rbETBQvgo8vbgLrBhgg/CnTWXL6jES25/PIp3mVgSGVyfiuFb2wZnuHYyMj5x WIAA== X-Gm-Message-State: AGi0PuaCP77Wshij/3I8bWQU+zPsPQ0U6eg+HF4EmwJLzFbfcklc3pdd YnNiWAlMI5dTBo4PrisT5tY= X-Google-Smtp-Source: APiQypJKBBEf01wRWMN+GHECJ5BOC84Qk5vs0oTHMJZaRLo2HQdhNnL2+hlM/MlNVD4Fkjjcd37M7g== X-Received: by 2002:adf:cd12:: with SMTP id w18mr35669483wrm.177.1588108249381; Tue, 28 Apr 2020 14:10:49 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id c25sm4620030wmb.44.2020.04.28.14.10.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 14:10:48 -0700 (PDT) References: <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> From: Dmitry Gutov Message-ID: <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> Date: Wed, 29 Apr 2020 00:10:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 28.04.2020 23:09, Paul Eggert wrote: > The word "constant" means different things in different programming languages. > The meaning used in the Elisp manual is reasonably close to its meaning in > C/C++/Fortran/Common Lisp/etc., and that describes how Emacs behaves now. As we've pointed out, Elisp is a wildly different beast from C. Static vs. dynamic, etcetera. > Of course not, but this area needs documentation and when the Emacs concept is > similar to an already-existing one in C/C++/etc. Not really. > Then I don't understand your suggestion. > > I thought you were saying that we should distinguish among the types of > constants and should say what happens when you modify each type. Which part of my example contained the "what happens when"? > A simple way to be clear in this area is to propose specific wording changes, > preferably in git format-patch form. It's not enough to say "I don't like the > word 'constant'." Could you first provide the list of your commits that changed the manual pertaining to this discussion? Then I'll at least know what to try to change. > Yes, and the documentation does that now. The edge of the wild is the line > between constants and non-constants. Write that line between fizzleworp and non-fizzleworp values. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 21:19: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158810873219187 (code B ref 40671); Tue, 28 Apr 2020 21:19:01 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 21:18:52 +0000 Received: from localhost ([127.0.0.1]:41778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTXcy-0004zP-59 for submit@debbugs.gnu.org; Tue, 28 Apr 2020 17:18:52 -0400 Received: from mail-wr1-f53.google.com ([209.85.221.53]:35499) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTXcw-0004z6-WB for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 17:18:51 -0400 Received: by mail-wr1-f53.google.com with SMTP id x18so8295wrq.2 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 14:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jMYA48+msikQQ/tSvJg5DS1ihOsvgTZs5Yy9Sk3Kg+8=; b=ekOXdui9QQmTf8jwK4SgqAyxo2cfMPPXCHpVYiDMJ0Gl4SDdq4rAiiSi07w3twgThB SHlKzteAU/z/iD+8lfbfEKItUIMYsxLr25LG7fJ0dUb6xBP3aWVCQqEzyz/jBHZJQl/A g2aaI3ee18VFZqoU9M+0BWUGJ01WxGqlleZOWjEbOdS6d2kOojWJtoCF/JYtfIGlgEmK u2ByvWdgVICBY6nmD1jDWjoPQA4u39TQ4TqDLkrmjLLxUqTaP4OpU51yOKB71fS2tYC+ 8kOzbA/NU23iM8vRk4XsNj8c+WixtssI2N2BPNwEkISTA4Xu/ASMZfhoAFZgfLiZT2lT k0Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jMYA48+msikQQ/tSvJg5DS1ihOsvgTZs5Yy9Sk3Kg+8=; b=BSH/lum0EcVn5hS3GA+YMt4EatH7QGTfbCAwAbcN06Sp29Nuh3kOc1GDIvigDVsSb3 Fb2SgrhGkakLi0Qnm3QTxZnzCng/b4zvB69pxhzWu3rhFoYkF+ydFkcsATiNw8fdZfTc pdUOeqGOqgwDLJ9P2AsMHUBL96sRcRpvFVZsMvY3dLsTbIBDgtKkWFAWjhy/2Kj7b3Sz 0xtYOiXHa/wrR2sbILuvT8hgyvww4j/zOqLKXAcirPlo0Ph1W/z7jLt2w00EtLtzO/9z IJKuQdgbMGEF861TRBJEtTefDhlBfO6GKon5vZ5wGChnIug7EKhEqzCG+qnj71+9+Q2Z T9zg== X-Gm-Message-State: AGi0Pua1qqJxNbA4aTXqf/v77axnk9hwWc5+4UrhXABUfjTqK0DAou+g 4w8ikckWVOTFN2GVaIBxedo= X-Google-Smtp-Source: APiQypL+mZG16H/WBVGPNKXMuz+gCyJ4pKvgI00vMK6WaPVjK/qPT3gSO8vUjWuvRNVBu/yuIc2K2A== X-Received: by 2002:adf:e2c2:: with SMTP id d2mr38013582wrj.55.1588108725112; Tue, 28 Apr 2020 14:18:45 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id i19sm28167020wrb.16.2020.04.28.14.18.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 14:18:44 -0700 (PDT) References: <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> From: Dmitry Gutov Message-ID: <569ca814-8337-bfea-97a6-ecd3d9c3f4f5@yandex.ru> Date: Wed, 29 Apr 2020 00:18:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 28.04.2020 23:09, Paul Eggert wrote: > I thought you were saying that we should distinguish among the types of > constants Among the types of mutable values. Between the "normal" and "do not touch" ones. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 23:12: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158811547030367 (code B ref 40671); Tue, 28 Apr 2020 23:12:01 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 23:11:10 +0000 Received: from localhost ([127.0.0.1]:41845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTZNX-0007tW-8w for submit@debbugs.gnu.org; Tue, 28 Apr 2020 19:11:09 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTZNV-0007sy-8k for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 19:11:01 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E259516008D; Tue, 28 Apr 2020 16:10:54 -0700 (PDT) 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 5F-bwd11q1Xo; Tue, 28 Apr 2020 16:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0D759160059; Tue, 28 Apr 2020 16:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 oJh-XGUCm4Wy; Tue, 28 Apr 2020 16:10:53 -0700 (PDT) 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 8CFC516008D; Tue, 28 Apr 2020 16:10:53 -0700 (PDT) References: <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Tue, 28 Apr 2020 16:10:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 2:10 PM, Dmitry Gutov wrote: > On 28.04.2020 23:09, Paul Eggert wrote: >> The meaning used in the Elisp manual is reasonably close to its meaning in >> C/C++/Fortran/Common Lisp/etc., and that describes how Emacs behaves now. > > As we've pointed out, Elisp is a wildly different beast from C. And Elisp is also wildly different from Common Lisp, for some interpretation of "wildly different". But it's close enough in this area. I don't see why we should depart from terminology used by C/C++/Fortran/Common Lisp/etc.; it's reasonably well-established. >> I thought you were saying that we should distinguish among the types of >> constants and should say what happens when you modify each type. > Among the types of mutable values. Between the "normal" and "do not touch" ones. The "do not touch" values are called "constants" in the documentation now, just as they are in the documentation for the other languages. I don't see why values that should not change should be called "mutable". And even if we called these values "mutable", I don't see why the documentation should distinguish among the various types of "mutable" values that should not change. The whole area is messy and differs from release to release and from platform to platform. Programs should not change values-that-should-not-change and we shouldn't try to catalog what happens if programs do what they shouldn't, since it's complicated and we often don't even know what'll happen. Generally speaking, the Elisp documentation should just say "you shouldn't change these objects", like it does for C/C++/etc. > Could you first provide the list of your commits that changed the manual > pertaining to this discussion? You can run this shell command in the emacs-27 branch. git log --author=eggert --since='Apr 18 12:59:17 2020 -0700' > Write that line between fizzleworp and non-fizzleworp values. I don't understand this remark. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 23:38: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.1588117029329 (code B ref 40671); Tue, 28 Apr 2020 23:38:02 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 23:37:09 +0000 Received: from localhost ([127.0.0.1]:41878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTZmn-00005F-CD for submit@debbugs.gnu.org; Tue, 28 Apr 2020 19:37:09 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:37342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTZml-0008WN-8m for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 19:37:07 -0400 Received: by mail-wr1-f45.google.com with SMTP id k1so343093wrx.4 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 16:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=muYXkay3g+sIvGtJDFocsjc3qi9d+auSzmdR8CayQAM=; b=tt3hkcRPL2rsIkMu5vsmwM56/mAideXiwrmtIZ17aY+nPFKsVI90h7lAuA3tdNGuOJ yUNl/Kaqq6Xhg7siIDGajTA6r0gX8p3L3I8aMQ+5hryfp0Abum+IL7jepxaxBhjFeIJO P/miD4UGdXAKIRhi8ohjliTntiFLr4xGapQYLV456DK8GxhpPWCGfqw8jppRFP4zSqTi 3noMqI36U1VU5r6h3g4nJRabJ9rY6a31MOhUIcMFkwUsVQ8uvzHGOapDlp9qA9rY/X5I 4ZgengHBwbEGIl00uNe3zW1NqJwvohrrppT0JYq8izl2zuQlPTM/gF7uemjrZptbx2gM aQ5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=muYXkay3g+sIvGtJDFocsjc3qi9d+auSzmdR8CayQAM=; b=C9Y3tYoj3bx/E1WLmy40c3WALEL2vOVw8k+WOHt+ZkBqsZkZLmn33iRvWoq/xtzvHi wKyTLXd5bUNrCDe/kJo+60IuXT5rnxhikTTFsJLCYnb8J03GEwJsPjaq5IHuQy2ksTk+ X/GnP7U6CTVic4D7ncXFalULpr3q9yvAL/fruK3rjvAuFV+u870+D9nsgmT1PMlDobl8 DJk3QIXWFOo7yLFvphF4QF90YlvOkUeeSB4ePrXhBfI0edExep6jsnRHS+p+MglbUq75 FBxE978cCCEhruMqcRFYrhgRrlnCECQ+EOl8QKh3+Km2CktNcZxWEH8nVv8rlgZj8tis 4bIg== X-Gm-Message-State: AGi0Pubg7CcdWFogaf3PAH1ZeXk5XSDeZggEqtD1MW6pm3eVMw7A1Vmg CHdHwyPWvKj4xvnhe/j3Du8= X-Google-Smtp-Source: APiQypJQFXZHcrvsamY48iGYzUiM7IOvF7bNUPYDSwSSuc4M9GGaAjz3f6OJGNrzItluyQ67qa76xw== X-Received: by 2002:adf:f30c:: with SMTP id i12mr37319317wro.426.1588117021297; Tue, 28 Apr 2020 16:37:01 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 91sm29605157wra.37.2020.04.28.16.36.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 16:37:00 -0700 (PDT) References: <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> From: Dmitry Gutov Message-ID: Date: Wed, 29 Apr 2020 02:36:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 29.04.2020 02:10, Paul Eggert wrote: > The "do not touch" values are called "constants" in the documentation now, just > as they are in the documentation for the other languages. In other languages, constants are something you can't change. > I don't see why values > that should not change should be called "mutable". Mutable values are ones the user _can_ change. It's a structural thing. > And even if we called these values "mutable", I don't see why the documentation > should distinguish among the various types of "mutable" values that should not > change. Because the user sees strings and conses in both cases. All mutable values, and yet changing some of them is a bad idea (even though Emacs will most likely let you). > Generally speaking, the Elisp documentation should just say "you shouldn't > change these objects", like it does for C/C++/etc. Do you see me arguing against that? From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 23:53: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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Drew Adams , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881179661747 (code B ref 40671); Tue, 28 Apr 2020 23:53:01 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 23:52:46 +0000 Received: from localhost ([127.0.0.1]:41886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa1t-0000S7-WC for submit@debbugs.gnu.org; Tue, 28 Apr 2020 19:52:46 -0400 Received: from mout.web.de ([212.227.15.3]:55849) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa1r-0000Rt-S3 for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 19:52:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1588117937; bh=smlYmXFmlU1XNI6PVKmLRPWI6c8qjvpAq9YRTOVd0ac=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=Xghk6DlJcsRve1+KQkde2FgZHzSOzCHv7JrBf4/Eh6q3+U2NxGi/heGvliVCXM169 92zj7QckF8cIOocqWutlj/r7wZhB4Bxb0mYs8XUzQlrnmxd57v80niA+7u5JhRoqSE RM/AXqpHYL1CtIoR5MXzDEn1i2UCxd2Zc7iXYVI4= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb002 [213.165.67.108]) with ESMTPSA (Nemesis) id 0LvS5r-1j3prO1FVj-010ZIZ; Wed, 29 Apr 2020 01:52:17 +0200 From: Michael Heerdegen References: <83tv1finob.fsf@gnu.org> <1E9E4C19-37C2-4E24-91B7-8101F9CFBF35@acm.org> <527dc4b5-3176-38b5-f2c1-1483ffc814a1@cs.ucla.edu> <87k12b6sv2.fsf@web.de> <2225099d-16e1-645d-0342-a054da53363f@cs.ucla.edu> <87a7376nv9.fsf@web.de> <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> <87o8rnasfk.fsf@web.de> <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> Date: Wed, 29 Apr 2020 01:52:16 +0200 In-Reply-To: (Paul Eggert's message of "Fri, 24 Apr 2020 19:22:22 -0700") Message-ID: <87ftcnp3rj.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:uUA9aqRZl7TvJ3zWUK7aKHTgorrL8v+PPDJUW548CPa94OZxtxq CLqSYKMwTihn7KpXqht8JhkgW1WREO9bY/VczFv7nLvbXJbiK75JdR5FWiOMppJwVUY9Phn DnvH7jKCP5/hKr8qjkikFlBZ+grB0xFB16ihHoXBUiamCojwugqg9CS8DrU8Uuhk7ZKuqgj Esb1E47nPqrvsJKFs5L5Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:kqcO1CuYZrc=:pPcrNzDO8N3XMnDNEcAtuD IoWw+HbBZLP/6p9MtbWJOyeDURMOYG9THnnpu8vmKaPGK1fdaibhYNHgwn96fBD8JHJ5J33Il 26QCB709jSZ0bVuAffwnI9UYqjgmsSp9PzT1u33trXuXYN+gpNz0F915E4sk6wEOvVDVpfUyU WmpkHqnch7b7AiGWmBV5fICz7caKs4vqznWg83fkyJcNwkJD5Tij+8KrpXMblw8H/QRrudCjM 2ca5KOkec70Ih3t5RNImKOOKdMFgSaC/MU+1ZQl5q61nkkzoiCGvH4tQaAaB3jQy3VZjBTHaa ghsbmVWncK0/FiGCOMz/NUcINBo4NzY4wkRcO4C9qUBP9WUUHLMBNUyeya3yZSVZ0Km26U3SF bBVqNnHi8XDag/cH8t5tq8wVQeaxfzDH4y7zC3Vff308BrDmj9uv3qbPF5sMgxocQCgpGa0iw DXkvmxjcqBwejimENpye7fbdgi5Eu37vxuLHAqzxb7wKwLPKahJtnWWkMkAduto6lAeyxi/3J liXiTysxi1OTzRNFejTsJtCR4EpQZmu8sQRWbgMlbl5nu35JSkFVTlli9+HSz9rsRF40CNEhl +i9cGK0D28SPI6BguRDGb8f2wX9dSB+dB26Qis8hxgPUg0HX1p0xy/nuF5CCqRs18ZK0wt/3Q iZ7cXg+FNI0wlw48iF8kHXg9A63ABHNDnoWfMtVJ+NshDEACUBIJStz1mdVXfnYJU2gVohLi6 1PBBfOsfLwScr83MJ9RPNz/HS9p2nFUZPyLAtUlDeFuN0xiLOZOhSpigFemVOuZVXpyA2/dkQ 4WDIItQDpZnG3TcFW7P4TKiJnwBhiYeFBTr+cjPDwu7sfH7+mJNd48FNw75YTqOdj2d4wA78w i84Bd8MhBBztwqkgLWyYl4vfeECNEld+0lwbF9HBhrJ5e6QpEP+SKe6LuWW5k1f0ZpVWVqz+r btEGxvbOf5y/YxNXxoGyvmT8uUDSMCjIkc63q89s82BogXxV7jZWF5M6wo8jPv8epv0rgzpKn 5c/7PYpSJufV9ra4Fb/YErjRmLBvaREwqoGehNNENFtjiMHyieFgRJXxcUwdkAQc8gXJFFc+4 jNBshUXy/Tsjbp8EOPAgJpFcSMWeBIT9ZJ1MeoWt8nFk8pQkgzTAepjeZ1BUdUa3pPjqsqWwH 4Fk4RZkag0l4zln+vBtLm1NXLsPjwa8MiVA19X1Kbt1QKzmhk7xcUEKOlDUz+XitZlcAd7iYe LZKWxGTiFlcc2q9QE Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > > (let ((l (list 1 2 3))) > > (funcall (lambda () l))) > > > > Has the list become a constant? > > No, because the list is not part of the expression that is being evaluat= ed. > However, something like this could cause trouble: > > (let ((l (list 'lambda '(x) '(setcdr l x)))) > (eval (list l l))) FWIW, I asked also because `funcall' seems, at least AFAIU, share some code with `eval', and with lexical-binding on the lambda gets transformed into something that does include the original list, so the list becomes part of the evaluated expression. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 23:54: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881180051828 (code B ref 40671); Tue, 28 Apr 2020 23:54:02 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 23:53:25 +0000 Received: from localhost ([127.0.0.1]:41890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa2X-0000TP-D0 for submit@debbugs.gnu.org; Tue, 28 Apr 2020 19:53:25 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:38068) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa2V-0000TA-Ls for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 19:53:24 -0400 Received: by mail-wr1-f51.google.com with SMTP id x17so372549wrt.5 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 16:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KTJ+8zGRSdJYlM4VWRvsE8Fi/unaHcn8XB3t1ka4gOo=; b=O0TLESxehGntA8I2MlfOaJE2cE2qE6y/fNlnYTmsVzLoi+7+s7CzDsksx85teP+62t djrEoQFqrNr+QKS+350XPvPOiwb4puplYjE7FgQANPwANUuSXlFtKj+Epmg+libm0fbW WVAFlVfgif18BA/bkoFGREj4O30wNmamrnyV+Z2mdKbjtVjTtknIqicogyiTCC6c40Be vp/kC56Qfi8Kbn2IMVhuQQT7LCgsB5zd+pHAh6qO5fEo5s+F4zXCcF0Bff4u5cdi8eEN 5xGGw7E1uSu7M8cuas2JiYGxdpYoPvEE+CqZyf8Y8m5eQWFlfmS29OJb9wo5Mi/OeOLv WUSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KTJ+8zGRSdJYlM4VWRvsE8Fi/unaHcn8XB3t1ka4gOo=; b=BRt8QdBpS7A4KQBAoYoZq2j92Hfl7PqoxgKdCmgu9Ho8ZgEXI3IxIfzImO+tPainAn 1ykKInrrVyp9LTl4N2s+B8Sj/vPgPsoEfYf9xGiHBYlLfK0HTWOJXkrkGBVKvb41VOK3 NW23pj2fbQOtDWtaQ1wRdSAl+ZkbvD2QGNbXPzvTAL1AkMK+LkNaXqwiJZ6juvrN46ON aA8uY9eWygbKuS34kv5phJ6l0naOZ7TMWcuIOP6zbktGXptVLesqpRoTchexRboQi8Gk n6axvT7BU/RORdoQsOXmwaWS59ijkITZY+IGsbCW0qOw2TwMSpTrl6Kqw6KLBg45Cp6S km/A== X-Gm-Message-State: AGi0PubsnpG/3bn6NgIusxm4DV2RYQR2vPDOvNeptB1CNOZZGsjqME04 TPepDovoDpG4osvIaMV3MPI= X-Google-Smtp-Source: APiQypI9J2U1wxuH2wCExgstRdmZqY59FBYkb6y79M8rOO8Q2p7lXP6+kq0ijCAzNrph3dbv11IUNw== X-Received: by 2002:a5d:4fc6:: with SMTP id h6mr37879298wrw.277.1588117997820; Tue, 28 Apr 2020 16:53:17 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 19sm5143287wmo.3.2020.04.28.16.53.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 16:53:17 -0700 (PDT) References: <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> From: Dmitry Gutov Message-ID: Date: Wed, 29 Apr 2020 02:53:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 29.04.2020 02:10, Paul Eggert wrote: > terminology used by C/C++/Fortran Quote from https://en.cppreference.com/w/cpp/language/cv: const object - an object whose type is const-qualified, or a non-mutable subobject of a const object. Such object _cannot_ be modified: attempt to do so directly is a _compile-time error_, and attempt to do so indirectly (e.g., by modifying the const object through a reference or pointer to non-const type) results in undefined behavior. Emphasis mine. I'll take a look at the commit, thanks. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 23:54: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881180141849 (code B ref 40671); Tue, 28 Apr 2020 23:54:02 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 23:53:34 +0000 Received: from localhost ([127.0.0.1]:41893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa2f-0000Tl-LZ for submit@debbugs.gnu.org; Tue, 28 Apr 2020 19:53:33 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:42090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa2d-0000TY-VM for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 19:53:32 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 639FA16008D; Tue, 28 Apr 2020 16:53:26 -0700 (PDT) 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 EIYloULWMj42; Tue, 28 Apr 2020 16:53:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9FBC1160094; Tue, 28 Apr 2020 16:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 FFVE6fb6Z7Pl; Tue, 28 Apr 2020 16:53:25 -0700 (PDT) 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 6589D160059; Tue, 28 Apr 2020 16:53:25 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Tue, 28 Apr 2020 16:53:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 4:36 PM, Dmitry Gutov wrote: > On 29.04.2020 02:10, Paul Eggert wrote: >> The "do not touch" values are called "constants" in the documentation now, just >> as they are in the documentation for the other languages. > > In other languages, constants are something you can't change. That's not true for C, or for Common Lisp, or for the other languages I mentioned. You can change constants sometimes and not others. Behavior is undefined if you try. It sounds like we're merely disagreeing about using the word "constant" vs using some other word or phrase (it's not clear what). But there's clear precedent elsewhere for the terminology now in use in the emacs-27 manual. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 23:58: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881182792250 (code B ref 40671); Tue, 28 Apr 2020 23:58:01 +0000 Received: (at 40671) by debbugs.gnu.org; 28 Apr 2020 23:57:59 +0000 Received: from localhost ([127.0.0.1]:41898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa6x-0000aD-7x for submit@debbugs.gnu.org; Tue, 28 Apr 2020 19:57:59 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:53594) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa6v-0000a0-8u for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 19:57:57 -0400 Received: by mail-wm1-f44.google.com with SMTP id k12so20837wmj.3 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 16:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2b00KqWnperISNsQpk+PyjrZqMQkzp4Z6iWPMm/5yfE=; b=YiQKPP3URB19LYLz5oiXbrpCSiebG5mCi4yHt4qYupHPwFrVYWs4Mjz6SphOpIkaVq ftKCJxImqBhAqfeEYVNYp1JLHbcONMeHHWBmUzYXqvJoj95qvZd6sSNEZ8/PpzGz375E 6h7KmRjv8F7DiCbaZR1I+zJ5kcDCQJlitND+Oog7nPyvrCo0HQo0Pdi7dtVRgjLxXydl Fnk32huAr7+GNCcyvDzFEWDZQYTNV4OXfXtGeJr2zbnvmeE2MwB2j8dr7ee3wBlZsr8b RkZh+IwehE2gQHYg4NvwRSPBOjyBP3DIczKrM1AnVFezz+PZ752cS7/q9kyjfB4pBM5R tEJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2b00KqWnperISNsQpk+PyjrZqMQkzp4Z6iWPMm/5yfE=; b=uKThwPQTvCktICOMYoy6Lj9OL398yOvzWDNuX15a3cUoBJ3+IpnlkpqoBwjclBYU0z xO8ZlYblP+LtXWTtGfpnJx7ULoyVDLvX+BNsjesMZ+k9WkKNKWPfEh4hIR3ugLfTt2jU tXdsOfYS8cCeg4d0ne/IjFdQ8X+yb4Sd9aOU+wvwCVCp9zKTsdIH1j0CvBOmemCwHql/ jFXZ3RusEuH+5/Kwf3F/DCh59uIRxkYKv3GUfEJCEbJRSSEJlv6wk2KpylNP2unPx8J3 781A2IDHzGIswBDYXqSvM1p3/KH7PjBm4PfSLutZZjWB+1AXMHR0QfFiyapcb2uZopGQ 5X7w== X-Gm-Message-State: AGi0PuZP4x+9KAI5X1vFGcEV5zOUF9oEEbB0EKbdR1LCCk4fEUQgDvYn SqtThB3Q0dTUK47j33HUBgA= X-Google-Smtp-Source: APiQypLXDw3JllG7lQZDCQJVUzwIRJcAJ+mWtwH0LdGqnti6SyRjEP0DLkMVACxMC8HQ66RltljxFQ== X-Received: by 2002:a1c:e906:: with SMTP id q6mr45716wmc.62.1588118271512; Tue, 28 Apr 2020 16:57:51 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id g69sm5664753wmg.17.2020.04.28.16.57.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 16:57:50 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> From: Dmitry Gutov Message-ID: <68407945-29eb-8006-7d2c-3662dc4573b0@yandex.ru> Date: Wed, 29 Apr 2020 02:57:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 29.04.2020 02:53, Paul Eggert wrote: > It sounds like we're merely disagreeing about using the word "constant" vs using > some other word or phrase (it's not clear what). I gave a couple of options. > But there's clear precedent > elsewhere for the terminology now in use in the emacs-27 manual. Any particular example? Before your latest changes, I mean. Please don't say 'defconst'. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 00:06: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 To: Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881187083091 (code B ref 40671); Wed, 29 Apr 2020 00:06:02 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 00:05:08 +0000 Received: from localhost ([127.0.0.1]:41931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTaDs-0000nn-3C for submit@debbugs.gnu.org; Tue, 28 Apr 2020 20:05:08 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44194) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTaDq-0000n9-9z for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 20:05:06 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8D7B9160059; Tue, 28 Apr 2020 17:05:00 -0700 (PDT) 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 LnW4fBkefeJc; Tue, 28 Apr 2020 17:04:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BEB1C16008D; Tue, 28 Apr 2020 17:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 Qu6DWBQfRUZJ; Tue, 28 Apr 2020 17:04:59 -0700 (PDT) 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 8452A160059; Tue, 28 Apr 2020 17:04:59 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Tue, 28 Apr 2020 17:04:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 4:53 PM, Dmitry Gutov wrote: > const object - an object whose type is const-qualified, or a non-mutable > subobject of a const object. Such object _cannot_ be modified: attempt to do so > directly is a _compile-time error_, and attempt to do so indirectly (e.g., by > modifying the const object through a reference or pointer to non-const type) > results in undefined behavior. It's reasonable to have compile-time checking in a statically-typed language, though (as the above quote notes) the checking isn't adequate for C++ and one can get undefined behavior anyway in that language. And we could add some similar compile-time checking for the Elisp byte-compiler: it could warn about misuses like (aset "abc" 0 ?d), for example. However, any such compile-time checking would be either too restrictive (with false positives) or only partial (with false negatives) or both (as in C++). So it wouldn't be an adequate substitute for documenting that some objects should not be changed. > I gave a couple of options. I recall your using "literal object" but that's not a good choice of wording because the problem can occur with objects that are not literally present in any source code. >> there's clear precedent >> elsewhere for the terminology now in use in the emacs-27 manual. > > Any particular example? By "elsewhere" I meant in other language documentation (C/C++/etc.), not elsewhere in the emacs-27 manual. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 00:15: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 To: Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881192724017 (code B ref 40671); Wed, 29 Apr 2020 00:15:01 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 00:14:32 +0000 Received: from localhost ([127.0.0.1]:41951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTaMy-00012j-3g for submit@debbugs.gnu.org; Tue, 28 Apr 2020 20:14:32 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:43368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTaMv-00012V-TV for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 20:14:30 -0400 Received: by mail-wr1-f43.google.com with SMTP id i10so389103wrv.10 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 17:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Y2WMZf1C4lyr8bueEo911O9ejEUlObqcAd6RxxxdauQ=; b=nIZOed4lV5JfJsV1wweDzqEOJ35pYVpCi4pwnWRYLczZTSXZvVApoiASPzvz64ksNK p1FjckEbdLVbdu6mUqDswxXMfl532zj2k+Khai1BE3mG1NpDIxOvffUjCEO9mMDI/FjL bQZxS17+KVFOutBBkMnziX6PNjQ7FljUvdB4iopga05rhnIUwpiQmkdiEkkMB0PnDCSp 64agdFEsGSrvE438VSa+BXX3jt0cZ3UQZd8S8Q+HpCJIvePmaS7fL/W9b1XY6Nr+FmRs yyDnLh8tBS0dFr+anQio1iewDdDgq4eB0gqlfXGFPBRuhAgb97WZmJB3INaIQkpvZhiO AGzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y2WMZf1C4lyr8bueEo911O9ejEUlObqcAd6RxxxdauQ=; b=nPYFCVoaWtulxrXc/FzuWXljgoD2r2AKZ2QWiwS5eMAQOeNpKlXv5BmJIAhMeL7Uxr Q2zHWMjAsbqDFR5MV43AFMGfmmKu2a9NOXKd2fjlATXyLLBSRiZgxuyZa261LA3zsFG+ QjgQ+MeZrJFqQbBlYfHRjEjJQmn8UiCS0ePUho2Il5rNy6MQlEJMPJS3hxXCBRNS4W18 J1qmAkuqaYsMgnZV7ulXa4TU7vo55fVvioesnNqAeTJmijjOw6bADmYQ6aa4i1LX4AAM HUp22xZOGyGqdIFNiPKL6HCkj2t4f6PUg/SWhs0+GSpxSugKAfKIrc+xQaGWSbE8LYpz t/Pg== X-Gm-Message-State: AGi0PuZpxju/aEGELzM9sk3x7M2yKpCge36cv8SzX3tzOPZGMIJ2B9Cc 6NXbd7faeMacSE5Ku3qvUJE= X-Google-Smtp-Source: APiQypLPF3m8icfsCU62rAOFcYkFpZBB4Ugk83cNR93eceOzwlbdrHQFfBuErnycTtHOw+s1T99B9g== X-Received: by 2002:adf:9564:: with SMTP id 91mr37052935wrs.246.1588119264266; Tue, 28 Apr 2020 17:14:24 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id d143sm5213215wmd.16.2020.04.28.17.14.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 17:14:23 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> From: Dmitry Gutov Message-ID: Date: Wed, 29 Apr 2020 03:14:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 29.04.2020 03:04, Paul Eggert wrote: > It's reasonable to have compile-time checking in a statically-typed language, > though (as the above quote notes) the checking isn't adequate for C++ and one > can get undefined behavior anyway in that language. All the undefined-behavior stuff in the language is part of backward compatibility with C. Like I said, the same argument that says "you can change a const in C++" also says "string and int and void are basically the same type". > And we could add some > similar compile-time checking for the Elisp byte-compiler: it could warn about > misuses like (aset "abc" 0 ?d), for example. Not the worst idea. Won't work: it's a dynamic language. Hence the example of how a similar problem was dealt with in a fellow dynamic language that I wrote about a couple of messages ago. > However, any such compile-time checking would be either too restrictive (with > false positives) The "too restrictive" end of the spectrum will result in prohibiting the user from modifying any and all conses. > or only partial (with false negatives) or both (as in C++). So > it wouldn't be an adequate substitute for documenting that some objects should > not be changed. With runtime checks, it could. But that might be too costly. > I recall your using "literal object" but that's not a good choice of wording > because the problem can occur with objects that are not literally present in any > source code. "Any object that is part of a literal value". You can probably extend that sentence to be exhaustive. > By "elsewhere" I meant in other language documentation (C/C++/etc.), not > elsewhere in the emacs-27 manual. In "etc", you mentioned Common Lisp previously. Any idea how it deals with that problem? From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 00:33: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881203735727 (code B ref 40671); Wed, 29 Apr 2020 00:33:02 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 00:32:53 +0000 Received: from localhost ([127.0.0.1]:41957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTaei-0001UJ-Ma for submit@debbugs.gnu.org; Tue, 28 Apr 2020 20:32:52 -0400 Received: from mout.web.de ([212.227.17.11]:58905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTaeg-0001U2-61 for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 20:32:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1588120333; bh=FgrtIgL24G/cuM8Qs5I5n6R0eDdUqlTGAuMlZcgPd28=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=WFBbYvWKJ4tsv5RkY/k9QSYgBXj1wB/MMaqvu1FGKLelHTEVDcCEyp3Xp3CMNsJ2q Y/y5cQzoOSVoTW/P/Jfq9bgTRCy4kCU2uG3Ienn9ylugBQKfKuMn/zIKOiVC45WmHP 2/vWm7ilWfUlut5ey0+Pg84iVTtIK/k+53RrBUEY= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MLRYf-1jlwTe0zYJ-00IVAe; Wed, 29 Apr 2020 02:32:13 +0200 From: Michael Heerdegen References: <9e6c138d-cb9f-6075-34df-a8d1d931343b@cs.ucla.edu> <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <1080866d-778f-493e-9c51-3893eeaf7203@default> <3aa1e901-c74e-e2cb-f47f-99aa939f3821@cs.ucla.edu> Date: Wed, 29 Apr 2020 02:32:11 +0200 In-Reply-To: <3aa1e901-c74e-e2cb-f47f-99aa939f3821@cs.ucla.edu> (Paul Eggert's message of "Tue, 28 Apr 2020 10:47:42 -0700") Message-ID: <87blnbp1x0.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:EmgAbpudjyKDjABmE2ua04jyQm6B6ILaeNjrbkJTKrjoBupW4YI fLjObpxga+BDXWbLQCvl+M7dAdy0NOMKbwP1GCrCZjjyPaCmJZqmxydEn+yS4AFUeZa7Uo5 7MMPfrAgo1gbSQgwCJ/mQ3ncovL0WAi3KQChgZKg9qxHjfWwOCA1Gb4f+kM0Qk1waJpIy+K 81RtqhGRB8sHFRM/LnVTA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:gkDg6GtArII=:W6LliTZW1Z5WnBMfHkpzJf vvzHrcrD9WhzV5AZ1OGhzOrwfvQpHnsurWIRkOcIEIPSSy9No3EEPhfRcnFOLRx/jWCWROwwM go5VIB6mtty+SzqUaRRQC8wIf5VdvJFgrEpot3NxFBiDlDW6iEnxsvAwywCxqoLaABebhqBZq R0jKp/djuzz7q8PFc25FlAaqd1Dzdggwtv2C8i3HAkdfpwUjvktd4V4cXsJOPn3lo9CK6uCK/ P36ojDkgjCXoIymiVbmR7VKqi8Hq4HEGy0+OAIy6uahC4NqO+DDcbfnaR+5KD84GVS/XUv3Pc YgRBXyJLuyoiStQggOOnUZzPpSEV7WhdbB34YtiTAxF1z0hzX8WmvfntEyj1F8D9qdKMjaMsY JRBO2NVBUcKy0qBdUU0qE5+wSOecbQWdQX6fAVEqS6/4cRNUCMqp4HRtaUC7KSlM+TXxa18PG h9XeF1UYRRAoLadzebtmNggIylgI2Qucv8hK/qvIly2IEigdQ1mVZNSE9dihVUp5n61aOmP8n swIR1OIQiig/UOrGM2vvQRjWbOLLkZoniyEbLP0RZdw0fuL0hhDSDXD8XPk7HoefF9ZtDuEgz PZPtXCjc8AXfKkEYeGLJVF5+YZLvUcS5QdoZYNk9q0xpLeC/Xoj4VGH+bpvmDhGOYkZ9mSzuZ owapBzSECBVskjAC58vwI/xriWQE+UjS1o8yLBX9wkGiEkmGr/VTtkn5DxShKxNreFPCWlfx8 9gMRCCJIfN2KvgxLn9iuBIHZw3N0mQmW2W2zk0RrE+eEBxr6mOOzITZIe1Qo3PochH0RX5zQn 3ZX4KuIi1aRK0cDo0gr0bIwI/1iMT5AQgeRuC2iZOTPAr0JTn3GhGHFZjB17dbSFaZ0Jr72NY nmHxiuckJDACGPDv3wKUll/Nd/IZXAtdYoNWroCro9SNyQQ+cKNaZ61aX6uOaw3GmwtHsjs/b zJFKDR4WB7/LZibEP4Q8f5hxWnQIlAHczqvsknl2+XrhuWSjmokuEX44WBxIp9Z0Hu/9ZI0/Q VvIxezPEayhZRzCpruze8VUKQ88ZVeIJLIU6VzZ8I5BYnMNvNGGhQXe7SZ8qMr5S0BrLxFHAa 5W0QBeyzqQbDklpS0PNaCVzU+KxCFQ5v8Y55CSn26axB7j8SSPsu6tRzXdUHdhGiEni2DV8pz OETEIhG7p4CqOYcK8RXTk3WSkhp3LDs8+CqHs5FAbl19Ex4Zkwu2Q5ftNihffGpTAuBkmPQxw pV0yQeN+3QV0Gjph/ X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > On 4/28/20 10:25 AM, Drew Adams wrote: > > Has anyone agreed with you > > Nobody's happy with the current documentation's language (not even > me), but nobody has proposed specific wording improvements either. I think the feedback would be better if you had been more cooperative/ open minded at the beginning. You have started committing stuff without even asking whether people like your approach in general. What if people think slight rewording is not enough? You started the thing not very cooperatively, and that's how things developed. Just my point of view. > That's what committees do sometimes; we might not agree, but the guy > who does most of the work generates something that nobody has the time > to improve significantly. We all do stuff here nobody else has time to do. Obviously, in this case a collective brainstorming at the beginning would have been better. Apart from questions like "please give me a better wording for this I wrote if _you_ don't like it", why did you never ask "how could we improve this aspect of the manual, what do you think?" or "do people agree with what I have in mind?". Now stuff is already in the repo, it's inconvenient to review, and the committer doesn't seem to be very open to other perspectives. A lot of the discussion here currently is rather destructive, yes, that's not good, I guess everyone involved is to blame. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 00:56: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 To: Paul Eggert , Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881217517778 (code B ref 40671); Wed, 29 Apr 2020 00:56:01 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 00:55:51 +0000 Received: from localhost ([127.0.0.1]:41974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTb0x-00021N-0t for submit@debbugs.gnu.org; Tue, 28 Apr 2020 20:55:51 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:43952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTb0v-00021B-ER for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 20:55:49 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03T0s1Hd136240; Wed, 29 Apr 2020 00:55: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=mSYbaPc15FBliYDTDcN1vOcV1IfadNreEuEh4yHD6E4=; b=c36bx744uXCyByg2Fuh09VQKML5s7jKSN5lHo2beRPpTblA1BgEz6naaFIrAz3nBD4Ik /GDoxxeECtRqVG3D860xe1CzKdDczHX1ius5aJd1nLaQ9coMKSeoRZob0JBwK40ciQgC hJhWMezoiq/m0VmZXSDOrRn50ZH9Xf72R2qvJw37sIMemQjPsQU0WQpU7wLC8jsAOqk2 tkzxIBiwCEkyrH322l8Hsfofnj5P6GhSRgYqZxUuR9gWcxYBFhrtGOmEPMhYo4L7q4Xl nHnbDDLtre67ctwzwATmT7LfrFqxrX+K3lY4sBpszrOK34+UoZyTrL7ufID7lw3KVM1W 4w== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 30p2p08et3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Apr 2020 00:55:34 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03T0ptSr175142; Wed, 29 Apr 2020 00:55:34 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 30pvcymesq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Apr 2020 00:55:34 +0000 Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03T0tNU5012374; Wed, 29 Apr 2020 00:55:23 GMT MIME-Version: 1.0 Message-ID: <278a1350-8b9e-4f3b-854a-723d578129f3@default> Date: Tue, 28 Apr 2020 17:55:22 -0700 (PDT) From: Drew Adams References: <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=807 suspectscore=18 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004290003 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 clxscore=1015 bulkscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 malwarescore=0 mlxscore=0 suspectscore=18 mlxlogscore=870 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004290003 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I don't see why we should depart from terminology used by=20 > C/C++/Fortran/Common Lisp/etc.; it's reasonably well-established. You're _not_ using the language that's used for Common Lisp. I echoed what the CL doc said. Elisp corresponds to the behavior of CLTL1 in this regard, not to any later update that makes the interpreter behave more like compiled code (raising an error in both). Like CLTL1, we should just warn about the gotcha, not say that it's about modification or attempted modification of "constants". A few mails ago, you wondered if the disagreement has been only about terminology. And the response was mostly "Yes" - objections to your use of "mutable" and "constant"/"immutable", and your use of "cannot" instead of "should not" (aka "Don't"). You've since ignored that response, it seems. This has dragged on, just circling. I, for one, give up. But I do hope you'll listen to others. And yes, Michael's point about committing before discussing & deciding is spot on too. Remember your curly-quote crusade? You did the same thing then, with similar complaints about acting widely, unilaterally, and prematurely. My suggestion is to see how people have already warned users about this gotcha here & there (forums etc.) and do likewise. Come to an agreement about the behavior to warn users about - in practical, operational, but not exhaustive, terms. A simple quoted-list example is enough, along with a general description. Once there's agreement about the message, including any example(s), the wording will fall out naturally. (At least the wording won't be a battleground, once the message is decided on.) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 01:04: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 To: Drew Adams , Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881222268613 (code B ref 40671); Wed, 29 Apr 2020 01:04:01 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 01:03:46 +0000 Received: from localhost ([127.0.0.1]:41984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTb8c-0002Eq-6G for submit@debbugs.gnu.org; Tue, 28 Apr 2020 21:03:46 -0400 Received: from mail-wr1-f53.google.com ([209.85.221.53]:42515) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTb8Z-0002Ec-W1 for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 21:03:44 -0400 Received: by mail-wr1-f53.google.com with SMTP id j2so483221wrs.9 for <40671@debbugs.gnu.org>; Tue, 28 Apr 2020 18:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xTpZGH3iNG96klLiF7CxZsYx5Zp67j/f7E+jpMnVzYs=; b=CkVSkjPRB5a5jZQK8fEOUMotogc5JHjUW28uFLmW9SnqjGE73WnV+dEHZHLMtr4S9x sp4TltIPurOEKv9nKlciNANx/muCge+hWCSV8s1DLrXLvFI1HvDIxFvXryAn0w4oF6R4 q2vrclTwfuUKVEZMzOuBio4GjsL0xBbC3fsI8SeeH8XuBB62PmIR3HiRF5UeCrlrMgyr 1dNbp4mowR+JsdEW7G5l0qECUdwYEBlfiuitHKcfbNIWwD/Vmu6vCat3BAHYxUII5vfB Db/3/I7WYrGnNaPfWF7OqT9sCroiLS2mUVYogVn/CMobE+R0A/Uqgp5mkSWZPmu5QDnf 6JlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xTpZGH3iNG96klLiF7CxZsYx5Zp67j/f7E+jpMnVzYs=; b=hYeHAtFhSAeiHnQ1OxWyhJYWiiO8WbPuVCi6vhkfOsQtoWOiKKOty9LaetmNfrDbuz U2IxSWLu9ajL9zoYImi5WFG9m66LXAiY5HrocN0ptgRerhpgEPgwJCGb2CVJ4F6m5CPg roQjedGJ3jtI1RzUQmo8UiK5JHkmRqHKidwAJvmNFHhdXXxaUhopG0gKBQK/+txjtXw2 ReadIeyWZabg4SlB6TPySc5Ko9q/gRKuoQ32E6370w4pCeocC7rRxBhbXVestLC0z0tD TrinNfLudyKnTDJ3O9vDSCaMn9vk47lHcR1ImV0OJP7Z5GdnqZ6f9idSMwTCJ0Wf6JS1 9ydw== X-Gm-Message-State: AGi0PuZVYzapE6530rp1mFYQOfXsa78fGouK+ZzZd0OXsU3IQzdR0HFr dT4Urid1YROkH6+rTD9pwvA= X-Google-Smtp-Source: APiQypJ6vBrcdlzPqJmBOTmdK6Nceb8vuUbYRe7s7UPOPuGWNsUzh+IVsKl7jDkoheem1v8XTbLhLQ== X-Received: by 2002:adf:8b1d:: with SMTP id n29mr35253086wra.196.1588122218042; Tue, 28 Apr 2020 18:03:38 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id x132sm5492012wmg.33.2020.04.28.18.03.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 18:03:37 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> From: Dmitry Gutov Message-ID: Date: Wed, 29 Apr 2020 04:03:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <278a1350-8b9e-4f3b-854a-723d578129f3@default> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 29.04.2020 03:55, Drew Adams wrote: > But I do hope you'll listen to others. And yes, > Michael's point about committing before discussing > & deciding is spot on too. Remember your curly-quote > crusade? You did the same thing then, with similar > complaints about acting widely, unilaterally, and > prematurely. I disagree about the comparison. The curly-quote was (still is) a fiasco, a big scope of changes (and breakages) with comparatively little practical benefit. This bug report at least deals with a real problem. And of course it's much easier to criticize (what a lot of us have been doing) than provide actual wording changes. So I wouldn't say committing too soon was a significant problem in this particular instance. It's not a far-reaching change, and we could still revert it. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 01:16: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 To: Dmitry Gutov , Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15881229199626 (code B ref 40671); Wed, 29 Apr 2020 01:16:02 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 01:15:19 +0000 Received: from localhost ([127.0.0.1]:41990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTbJn-0002VC-9t for submit@debbugs.gnu.org; Tue, 28 Apr 2020 21:15:19 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:57444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTbJl-0002Uw-Ga for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 21:15:18 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03T1DRLo164572; Wed, 29 Apr 2020 01:15:08 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=qYXFKCmlJJw+2CyIRmOVuI8985ol71DFxF5cnvzW4bY=; b=seX2yV9nCTQzL8MpXUb9ABfbzHBGlQTWeQD4gqcxK+CUJ7GLclkt2g43FDitkMU/ekZ9 vkc/Hz23fghJwfVoL1+0Pf3CKBnFRC2yyOuY3CnEa1aVjyhHxKsH/78d0avGdp4gPWPl imxDWPlp/M0JQmMgDebr2IZK9oWeG6VzHPUDwvQhfW3gtJnAZfM7TY1qVt0oMYo9FRng a5wza7QEFjr9cMMV9OTbkpO4Fo5OUqP+HG0oScJEidqbeo8vnAsXT/ga/SmDXXEXmoF6 Ed5gKW6za0ckMNUtjT8KljYWvqNriVaZ3VuwJ3jUKgr1zs0CtPaIlYkleCU/uz2W+85n 2g== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 30p2p08g6t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Apr 2020 01:15:08 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03T1D7bP030004; Wed, 29 Apr 2020 01:15:07 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 30my0f1a15-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Apr 2020 01:15:07 +0000 Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03T1F4vj011796; Wed, 29 Apr 2020 01:15:04 GMT MIME-Version: 1.0 Message-ID: <4f0db18b-3f09-46f6-a8c6-b2b6a25183f9@default> Date: Tue, 28 Apr 2020 18:15:03 -0700 (PDT) From: Drew Adams References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 suspectscore=18 adultscore=0 mlxlogscore=876 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004290006 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 clxscore=1015 bulkscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 malwarescore=0 mlxscore=0 suspectscore=18 mlxlogscore=913 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004290006 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > Remember your curly-quote > > crusade? You did the same thing then, with similar > > complaints about acting widely, unilaterally, and > > prematurely. >=20 > I disagree about the comparison. The curly-quote was (still is) a > fiasco, a big scope of changes (and breakages) with comparatively > little practical benefit. This bug report at least deals with a > real problem. Yes, I agree about that difference. > And of course it's much easier to criticize (what a lot of us have been > doing) than provide actual wording changes. So I wouldn't say > committing too soon was a significant problem in this particular > instance. It's not a far-reaching change, and we could still revert it. And I agree with you there, too. But I think Michael's point was about the cooperation/attitude, not the nature or difficulty of the problem to solve or the magnitude of any problem of undoing committed changes. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 01:29: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 To: Drew Adams Cc: ke.vigouroux@laposte.net, Paul Eggert , 40671@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158812368610786 (code B ref 40671); Wed, 29 Apr 2020 01:29:02 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 01:28:06 +0000 Received: from localhost ([127.0.0.1]:41994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTbWA-0002nu-EZ for submit@debbugs.gnu.org; Tue, 28 Apr 2020 21:28:06 -0400 Received: from mout.web.de ([212.227.15.14]:39179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTbW8-0002nQ-Jq for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 21:28:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1588123657; bh=uaYjqQuxrMgBEUpDQdphsRhEuI4pDlHnOhMYnfkYSOE=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=Lvtn8vm3uKtFQcvfM5a3YRLv3S0Sy3MZ+h9cqj/Id0CE3MFtIOvbuEAwuqa6boWLS 4azQnglvrf6AfZeyF6ylom454bsX20+WPQmlQnthXYShhp8fpc+4KUj/hbixSL7PaQ Vl54Tc9xeHNEbYmpTQlsAJ1KV7N9SeoJFqB1td4s= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MejjU-1jnJBp2k6y-00OGwp; Wed, 29 Apr 2020 03:27:37 +0200 From: Michael Heerdegen References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <4f0db18b-3f09-46f6-a8c6-b2b6a25183f9@default> Date: Wed, 29 Apr 2020 03:27:36 +0200 In-Reply-To: <4f0db18b-3f09-46f6-a8c6-b2b6a25183f9@default> (Drew Adams's message of "Tue, 28 Apr 2020 18:15:03 -0700 (PDT)") Message-ID: <87imhjnks7.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:7y2e+eWM043ezrQ1tPlp/l1lAj6d0VkbcTE6RacMjZBU44S455b Yq7eC+y2ux50fHN30XN0vosHi664/6CEqxyGMeVKbjukIT9/mxLyzfjHrZKtuKHDHAWLHLZ Wd09AhNRdxncyHiLz2mdBOCgbTQ7IdmCL4kXbi2Hf/85v6wLyGb88oGH1CRj1u1oPSWE8yK 5iR0BrGNtyMUpyuuf28jA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:PywIqgRm1pA=:wrEdifxPKMItwg7EUQjwD8 6YVCbc60tauqpNg7xX5rRgOTX6PiC5uPE2xRalJGmTyv0ILPHEQwbpCBF8LeLGKlV1a28Z3Kf UXy2DDjvtK8YZToQCnoJ52V7uoOcRYaVURHaTT3NeMOXkKpP2EKz5DehiN/+wJG07vhtwAxpz CxPS6Ic1wb0WO+CHOobTHv9THoL84IZQZfl3+D8AAfdrCNp963jwTAClJ1/PiB2DyBmpwpU4Y Xj23KC3BbbVrUCmO8qVtNgjgC6cblRezy5xVyR7VOsSSKxoxFEwR0/zIiiNf1OPkyEbKY8m5Z +WixXib5kUwVlNl+tbDcl4Dwfa2T8BkhUpX6XTLw/3wCQrGDx+MxKKh2F9bp4vfo1f4nDAH83 uQV9lhsmgZnLnGCMEyJcsyqSsYAcYRYvW7+mZ7JVV8nOhDLWkZLkPrPlJhUk3NlefWwGYUe0h 085ROm3PpO7f74LaHDJDguJWSIMYjTLf4JlbFydb4q5GqR2/cBpTJW4xYJfW2nxj3jnC3QGtu 2RKHGt11dZ8z71W68ctmku5fS8XU5W482OXc06jiXEIh0dK5fFe8EW2/cBucz8sl5OfWzU5R0 7EcF/yKyBf8IXxjqrF6ASApmRjvONs94eZ09Q5+KSSbo4aQETYMGOWkf9OKtKo4MhR9QNihpS gA5/e0Tu+AtsbFTVJ58+tK07RdPQxd14XJ69fqB21cUpHEp/yLdOuRV3UreeLczCAYKf9Uj5m yK3lr+NS8jxUw4Npu/fTdO4962pBhZWwIPZWAQ67aucpf45u5hccictEu/lWFQMfdSOeEDZ2d Tqs9tc7gyzm3i/RvGnTIsGq8MbrX6IjS9odcXHNQeSbTE6wmdh82eQId+naHBeGsWaBobYvLf tF6RLyhIcYWbNzDKiuNkbNr1frtMzOmuv7W9RZ6oshe20VyqL1ZbrPKlZD/bQjP2aeU2KTGDO 8pljajpymy4FqStdXMywWHBaUCT/6mTc6rxJ7g+7hgmzYmVY+hRno//HEAFbDdrWgPgY8j0kb TNuo/sS6ZOUESrCsWXkJKz55ql2ppalsSrehr9hkHXeH9lm3IJ1KWjzRdRS1lRw1TJFdl7d8A xx5UyMTolrDWF1j3suSIcC6d3t9bzWws5WyGvy5mzp2ZU4mMW6V1ekesdjlKWa9SMQEPn+pfi lQ1nUIs7TtuBpRO0xoN4cAN35SyxDcbozKUQ6yyd+QXkhTgwCiJnwfFWpb0LRZ+0FPBL+gANs OYbwTzYADjPYj8aAT X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > But I think Michael's point was about the cooperation/attitude, not > the nature or difficulty of the problem to solve or the magnitude of > any problem of undoing committed changes. Yes, I was referring to Paul's complaints and frustration, and I wondered why the discussion developed like that. Maybe I'm totally wrong, it's just how I experienced things. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 01:39: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 To: Drew Adams , Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158812433411842 (code B ref 40671); Wed, 29 Apr 2020 01:39:02 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 01:38:54 +0000 Received: from localhost ([127.0.0.1]:42025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTbgb-00034u-Vz for submit@debbugs.gnu.org; Tue, 28 Apr 2020 21:38:54 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTbgZ-00034g-Pc for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 21:38:52 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 45329160059; Tue, 28 Apr 2020 18:38:46 -0700 (PDT) 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 GPTpVHedrP7r; Tue, 28 Apr 2020 18:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 658D316008D; Tue, 28 Apr 2020 18:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 s9TouTG9BryK; Tue, 28 Apr 2020 18:38:45 -0700 (PDT) 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 BFB97160059; Tue, 28 Apr 2020 18:38:44 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Tue, 28 Apr 2020 18:38:44 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <278a1350-8b9e-4f3b-854a-723d578129f3@default> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 5:55 PM, Drew Adams wrote: > You're _not_ using the language that's used for Common Lisp. In what sense does the language differ? Here's a quote from CLtL2 (page 115): "it is an error to destructively modify any object that appears as a constant in executable code, whether within a 'quote' special form or as a self-evaluating form." This use of the word "constant" is consistent with what's in the emacs-27 doc. > Elisp corresponds > to the behavior of CLTL1 in this regard, not to any > later update Those older CLtL semantics were not well-defined, and to the extent that they were defined were not followed by Common Lisp implementations. It's not clear that the emacs-27 Elisp implementation corresponds to those older semantics, and it's also not clear that documenting CLtL1 semantics would be a good idea for Elisp. > A few mails ago, you wondered if the disagreement > has been only about terminology. And the response > was mostly "Yes" - objections to your use of > "mutable" and "constant"/"immutable", and your use > of "cannot" instead of "should not" (aka "Don't"). > > You've since ignored that response, it seems. I responded to those specific wording objections by removing the "immutable"s and "cannots" that were objected to. At least, that was my intent; if I missed something please let me know. I admit I have not made changes in response to vaguer suggestions, but that's partly because I don't really understand what's involved. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 01:41: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 To: Michael Heerdegen Cc: ke.vigouroux@laposte.net, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158812444412027 (code B ref 40671); Wed, 29 Apr 2020 01:41:02 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 01:40:44 +0000 Received: from localhost ([127.0.0.1]:42031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTbiO-00037v-CJ for submit@debbugs.gnu.org; Tue, 28 Apr 2020 21:40:44 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTbiM-00037i-Ma for 40671@debbugs.gnu.org; Tue, 28 Apr 2020 21:40:43 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 53740160059; Tue, 28 Apr 2020 18:40:37 -0700 (PDT) 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 c3mPuIKYSYq7; Tue, 28 Apr 2020 18:40:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 978C516008D; Tue, 28 Apr 2020 18:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 LyBoC5nJX-Pt; Tue, 28 Apr 2020 18:40:36 -0700 (PDT) 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 4A3CF160059; Tue, 28 Apr 2020 18:40:36 -0700 (PDT) References: <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <1080866d-778f-493e-9c51-3893eeaf7203@default> <3aa1e901-c74e-e2cb-f47f-99aa939f3821@cs.ucla.edu> <87blnbp1x0.fsf@web.de> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Tue, 28 Apr 2020 18:40:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87blnbp1x0.fsf@web.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 5:32 PM, Michael Heerdegen wrote: > A lot of the discussion here currently is rather destructive, yes, > that's not good, I guess everyone involved is to blame. At this point the disagreement over a relatively minor terminology issue is so lengthy that the whole documentation change is arguably more trouble than it's worth. So again: anyone who wants to revert my recent doc changes to emacs-27 is welcome to do so. Or, if you'd prefer to uniformly subsitute "literal object" for "constant", please feel free to do that too. It's really not worth arguing about, and I apologize for stirring up this hornet's nest. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 04:37: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 To: Paul Eggert , Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158813501528243 (code B ref 40671); Wed, 29 Apr 2020 04:37:01 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 04:36:55 +0000 Received: from localhost ([127.0.0.1]:42168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTeSt-0007LT-82 for submit@debbugs.gnu.org; Wed, 29 Apr 2020 00:36:55 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:48028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTeSr-0007LG-QW for 40671@debbugs.gnu.org; Wed, 29 Apr 2020 00:36:54 -0400 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 03T4X3c8065264; Wed, 29 Apr 2020 04:36:38 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=Tf4zeylY5nT3FkIqfuGHrcs4KhemrFvRbNbih/fIV5g=; b=xltbiBy9shkUv1T4h1+O5Wp6cwSFfpX9dJVwFgfyZTJ3pYUhOhBl+FbBLC1dWQfvyizm 2wUQGf1E/I6LryJX2vVe6rvdLHzZd1eCVJP6lYx1BUA4ciHGN9whewetWS0wEfEyFOQB tXSgEnLjsTQWmGOb93EN2JixTOagE1/q5xUaNU5KBeOdn8wbRVS2nSxCvAqLszVjLd9S kCBhM6HUBTeXHMSoMopeBYTxADJzHPkxNrZjy7qj1heDJAu6jTsSZIMIpFijUi8EJA6y Hkjik/3dynbYjmoxF6lclcse+RIYCxPcbk2mBECzd7ay4CTQJMObNg8o1ZRWdw3T9D/k Gg== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 30nucg3hx0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Apr 2020 04:36:37 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03T4Vver182873; Wed, 29 Apr 2020 04:36:37 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 30pvd01066-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Apr 2020 04:36:37 +0000 Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03T4aWG9007608; Wed, 29 Apr 2020 04:36:32 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 28 Apr 2020 21:36:31 -0700 (PDT) From: Drew Adams References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 suspectscore=1 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004290033 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9605 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 priorityscore=1501 mlxlogscore=999 impostorscore=0 suspectscore=1 malwarescore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 adultscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004290033 X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) > > You're _not_ using the language that's used > > for Common Lisp. >=20 > In what sense does the language differ? Here's > a quote from CLtL2 (page 115): >=20 > "it is an error to destructively modify any object that appears as a > constant in executable code, whether within a 'quote' special form or as > a self-evaluating form." >=20 > This use of the word "constant" is consistent > with what's in the emacs-27 doc. I quoted that same text as part of a proposal to FIX the very gotcha that Elisp still suffers from. I already addressed this, specifically. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D40671#24 I specifically spoke of CLTL1, because its state, and the state of CL at that time corresponds more closely with that of Elisp and its doc, since CLTL1 predates the proposal to handle the gotcha systematically. > > Elisp corresponds to the behavior of CLTL1 in > > this regard, not to any later update >=20 > Those older CLtL semantics were not well-defined, Precisely the problem Emacs Lisp has! And not just not well defined. Different behavior sometimes between interpreted and compiled code. That IS the gotcha - the fact that Elisp does NOT raise an error systematically in all such cases. It does NOT always prevent you from modifying a constant, quoted list etc. Elisp is like CL was BEFORE the proposal I quoted, which was adopted as the CLTL2 text you quoted. They fixed the problem for CL by redefining CL to not have it. For an implementation of CL to follow the updated definition, it must provide consistent behavior, preventing modification of constants, quoted lists, etc. Sound familiar yet? > and to the extent that they were defined were not > followed by Common Lisp implementations. It's not > clear that the emacs-27 Elisp implementation > corresponds to those older semantics, and it's > also not clear that documenting CLtL1 semantics > would be a good idea for Elisp. The point is that the problem they fixed is the problem Elisp still has. Whether it is exactly the same in all particulars is unimportant - it's about the behavior being undefined and not necessarily the same if interpreted or compiled. I mentioned the CL proposal, to take effect for CLTL2, quoting: "clarify that it is an error to destructively ^^^^^^^ ^^^^^^^^^^^^^^ modify objects which are self-evaluating forms or which appear inside of a QUOTE special form." Why "clarify"? Because it was NOT stated as part of the previous definition of CL that that is an error. And that meant that CL implementations were NOT required to systematically raise an error to enforce that. They did NOT always prevent you from modifying such thingies. The proposal also said: "Disallowing modification of constants ^^^^^^^^^^^ consistently in all situations, rather than ^^^^^^^^^^^^ just in compiled code, is proposed because ^^^^^^^^^^^ in some compiled-only situations it may be difficult to distinguish between "compiled" and "interpreted" code." That was the problem to be fixed, by raising an error, i.e., by disallowing, in practice. And that's exactly the problem that Elisp still has: it does NOT disallow (systematic error). And no amount of saying that it does (claiming you "cannot" do it) changes that fact. I quoted CLTL about the behavior before the proposal, i.e., before systematically raising an error: "implicit sharing of compiled data structures may result in unpredictable behavior if ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ destructive operations are performed. However, CLtL does not explicitly allow or disallow ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ destructive operations on constants." And about that I said: Unpredictable behavior. It doesn't say it's ^^^^^^^ always impossible to modify such things. It ^^^^^^^^^^^^^^^^^ says, in effect, don't try. ^^^^^^^^^ That's what we should say for Emacs Lisp, since ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ we do NOT "disallow modification of constants consistently in all situations." For Emacs Lisp this is a gotcha, so we need a SHOULD. If it were enforced as a MUST then we wouldn't need such a caveat. That's precisely the point. We do NOT disallow. We do NOT always raise an error. We do NOT always PREVENT changing quoted list structure etc. AND SO we should NOT tell users that they CANNOT do so - sometimes they CAN. We should instead tell them that they SHOULD NOT try to do so, and if they do then the resulting behavior is undefined. ___ I said last message that I gave up. And now I'm literally repeating what I wrote 10 days ago. You haven't heard, or you're not listening. (And my impression is that others have said the same as I, or similar.) Sorry, I'm done. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 04:42: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158813527428650 (code B ref 40671); Wed, 29 Apr 2020 04:42:01 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 04:41:14 +0000 Received: from localhost ([127.0.0.1]:42172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTeX3-0007S2-US for submit@debbugs.gnu.org; Wed, 29 Apr 2020 00:41:14 -0400 Received: from mout.web.de ([217.72.192.78]:53143) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTeX1-0007Rm-W1 for 40671@debbugs.gnu.org; Wed, 29 Apr 2020 00:41:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1588135242; bh=iIrUg1TC1e6+rqEuqoek1BT9MIBPjMxYevqrhCjM+k0=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=HCvs3laHzrutvGMI97LlGZW9cepYBjUtU9+dfHi+latLoFCKDtoq4ATKnluWt7FxC COiXV0mklFMn/oFqqDWDTqA+53OQ7PPiuBFWj7p5B0rjkMGO1i1tzbeewuZjUbnbr5 c4uFiESPflk074359lqhJD3Uh+A6OPEd944r6RPs= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.99.7]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MJkxE-1jUkSD3Xls-00195t; Wed, 29 Apr 2020 06:40:42 +0200 From: Michael Heerdegen References: <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <1080866d-778f-493e-9c51-3893eeaf7203@default> <3aa1e901-c74e-e2cb-f47f-99aa939f3821@cs.ucla.edu> <87blnbp1x0.fsf@web.de> Date: Wed, 29 Apr 2020 06:40:39 +0200 In-Reply-To: (Paul Eggert's message of "Tue, 28 Apr 2020 18:40:36 -0700") Message-ID: <874kt2oqew.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:nVj6cfrALqqqafvLColc3C+O3mP/DGxmrX2gdTm4CAJIfm+CImf 53QiXciGY9TofpQU/Z/HrcH5NOmpwpWS+vBpT5ZLKifx29BBEv2LidTM240Bna7/TtTW8EZ r8b7mYuzgF/HXx84pKvHb/iiWBoNK7aQE4R5xj8N9cODty96XBc9QPVw5enzUTsAiNi3/rN J/Pv7SuDVd3wtyr4m6SkQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:TdTNUG6KFAQ=:o/arz5j7yGkh0aBndJc0z5 GSLGuvu+npWaZ9oMgd1sTBfmtQs9mftRr679k7UT9XovmBrGhDc0+fBOoeyj+gbGVkP0V5SN3 BOnRlzeAoowZ+rzVgvvDjP7ryMKk/wZYPHESHrFX2tBmKtzvzLQRhGmHdJRm7SYNC85FB4EfI b/uJtTj4nRrjvDOGN9n6iYOn0ojFsi5sMH7d/85psu5jgg1158g3AOjJIYa+KkrXfZrcBhuwo HJo7Y8NK1+a38mMF5Y6/srudXq8okFQ/+ufbehA3HvnWGx/djdI91DOmaV9yy4kOIWkXk8WnZ E8g0tjtPpM4LN9Aiu6Vkp4801BGJIuy3cU/I01yTJvXzE4IENejbbiNy0wttjZqBT8TkiCLWj HMdjV25QCQ6SMwbypiswvw3KQxz8sMbuUMrjc4Gq7Htg2Ox5gU7ua2Htz7zEPlPREsZjkhvqn r2dFpjujLxaR5UyMP0SyQPwLeVafj+ef/kSD/T3ZNdtZSlDOOh+Snp47NBuJaE7oDGsSSSZAS 8J9ndwnHx0ijEIESMXjqNDli+lK4ryY8XvLXAq5Fp0OrMnIDxE47WrLVBskuHuDxMIDk7Lh26 vwADOX0M+ZB08+lXS6tFHAif+QuYrsa5gpWS5hH73/HqvNitDzO9nbyV/0LGwy/rFWVI7QnXp z2fojIqDmoSf8925WOpkVkuj96sVz2SGRXILaeXor9Fs0v+ILV5R404aHEZ1Wh3z0WKsIo8gI pLgh/Qc7cInyHStYJEKF3tb2qTt3nm9PZLaL1AKY/ktBUMtplcPAo0WPn+ZSQvFbXHDtmoWWs Tof0QsLD45C+POt6hPuU9S5G8o5eAfsbhP9OX+z6v4XC0hME53ijnF1QIaouHY2XyqyI83fwL q/qusmRncj66MkZKPM3u5kYWagV1UJflkyJwQxzX1nWE3mh2bjIrz2rPECcOVtusH3WUwDF8a xC7bcYflWA+emBno9RbHv3Ik+lAbDEwN7dmm98ikTgS29XwjlQZ9Ky1NnGzB4ndHuVh8FRxy5 MGCy/2elbO8Lv1ltb/zAApbKI6mRsZSEBz9haC/NUpjxsf0wHG88dxaxdW64PBRZ9V3HBLVZX 8zYTyzBPOhKHa7dyBKqkQh1bYhrE2srUtfc8kh2MOEaWIJQS2hKdNHjbZAOQ4df+aiJgtlbQT k08PhikJpBXvvyoP49TMd54spViyyFfEuF0s9ZPM/y5UE0QQEKE8uxTKKI6TM0RZa+LlIRBzA vn4XQlNWHmqlkv+5u X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > So again: anyone who wants to revert my recent doc changes to emacs-27 > is welcome to do so. Or, if you'd prefer to uniformly subsitute > "literal object" for "constant" I don't think "literal" covers all the cases you have in mind. I don't have an idea for a name of the class of cases you have in mind, because I would not subsume all examples you gave in one class at all. They might be implementation- or memory-wise, but I don't think this is a good perspective to describe a high-level language. For example, the result of `symbol-name'. In my eyes, modifying the result has a side effect (renaming the symbol, but in a way that is not supported), and this side effect will have undesired consequences. But that is true for other strings, too, that you would call mutable. It's hard to draw a clear line here, unless you think (C-) implementation wise. For what you describe I would just say that under certain conditions certain objects that are, in principle, mutable, should not be changed in certain circumstances because of implementation details, here is a list of such cases: ..., that's it. I'm sorry that I also can't offer patches because I don't speak texinfo. > It's really not worth arguing about, and I apologize for stirring up > this hornet's nest. I've never been called a hornet before. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 08:03: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 To: Michael Heerdegen Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, mattiase@acm.org, dgutov@yandex.ru, rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158814735015596 (code B ref 40671); Wed, 29 Apr 2020 08:03:02 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 08:02:30 +0000 Received: from localhost ([127.0.0.1]:42298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jThfp-00043U-O3 for submit@debbugs.gnu.org; Wed, 29 Apr 2020 04:02:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47636) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jThfn-00043H-Qa for 40671@debbugs.gnu.org; Wed, 29 Apr 2020 04:02:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49925) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jThfh-0005MF-1e; Wed, 29 Apr 2020 04:02:21 -0400 Received: from [176.228.60.248] (port=3351 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jThfZ-0000bD-OB; Wed, 29 Apr 2020 04:02:14 -0400 Date: Wed, 29 Apr 2020 11:01:55 +0300 Message-Id: <837dxy200c.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <874kt2oqew.fsf@web.de> (message from Michael Heerdegen on Wed, 29 Apr 2020 06:40:39 +0200) References: <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <1080866d-778f-493e-9c51-3893eeaf7203@default> <3aa1e901-c74e-e2cb-f47f-99aa939f3821@cs.ucla.edu> <87blnbp1x0.fsf@web.de> <874kt2oqew.fsf@web.de> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Heerdegen > Date: Wed, 29 Apr 2020 06:40:39 +0200 > Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, > Mattias Engdegård , > Dmitry Gutov , Richard Stallman > > I'm sorry that I also can't offer patches because I don't speak texinfo. Would you be willing to review the relevant portions of the manual and post comments to the parts that in your opinion need further work? I think that would be a good step towards making the text less controversial. TIA From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 16:19: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 To: Drew Adams , Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158817711016702 (code B ref 40671); Wed, 29 Apr 2020 16:19:02 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 16:18:30 +0000 Received: from localhost ([127.0.0.1]:44409 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTpPq-0004LJ-56 for submit@debbugs.gnu.org; Wed, 29 Apr 2020 12:18:30 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTpPn-0004Kx-NA for 40671@debbugs.gnu.org; Wed, 29 Apr 2020 12:18:28 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3F50E160017; Wed, 29 Apr 2020 09:18:22 -0700 (PDT) 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 5Rsyrasnpbyd; Wed, 29 Apr 2020 09:18:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 76405160066; Wed, 29 Apr 2020 09:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 ViEMrUy4rZFY; Wed, 29 Apr 2020 09:18:21 -0700 (PDT) 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 35222160017; Wed, 29 Apr 2020 09:18:21 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Wed, 29 Apr 2020 09:18:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/28/20 9:36 PM, Drew Adams wrote: > Elisp is like CL was BEFORE the proposal I quoted, No, that's backwards. CLtL1 was hazy, but arguably would have disallowed Elisp's behavior because it arguably required the interpreter to immediately respond to changes in objects currently being executed, and arguably required the interpreter to not coalesce identical literals, and the Elisp interpreter violates both requirements. In contrast, CLtL2 allows the Elisp behavior, so CLtL2 is the better way to go here. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Apr 2020 16:37: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 To: Michael Heerdegen Cc: ke.vigouroux@laposte.net, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158817819218570 (code B ref 40671); Wed, 29 Apr 2020 16:37:01 +0000 Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 16:36:32 +0000 Received: from localhost ([127.0.0.1]:44422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTphH-0004pR-TG for submit@debbugs.gnu.org; Wed, 29 Apr 2020 12:36:32 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTphG-0004pD-4a for 40671@debbugs.gnu.org; Wed, 29 Apr 2020 12:36:31 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 966C6160017; Wed, 29 Apr 2020 09:36:24 -0700 (PDT) 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 0G9KZq38xx00; Wed, 29 Apr 2020 09:36:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4BA11160066; Wed, 29 Apr 2020 09:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 Ofs9huFVdUNL; Wed, 29 Apr 2020 09:36:22 -0700 (PDT) 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 7B158160017; Wed, 29 Apr 2020 09:36:21 -0700 (PDT) References: <871rofxbz9.fsf@web.de> <93463227-33a8-85a0-fd19-8b29b75997f3@yandex.ru> <969b3497-0afd-d104-6792-d744d31548fa@cs.ucla.edu> <2935ec84-bdea-2e20-01b9-8ed08cc61c6c@yandex.ru> <669981e5-f601-5c18-1a8b-ee316ad001ec@cs.ucla.edu> <4b8b7e98-029e-58ac-59ff-6cd984b7eb85@yandex.ru> <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <1080866d-778f-493e-9c51-3893eeaf7203@default> <3aa1e901-c74e-e2cb-f47f-99aa939f3821@cs.ucla.edu> <87blnbp1x0.fsf@web.de> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Wed, 29 Apr 2020 09:36:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87blnbp1x0.fsf@web.de> Content-Type: multipart/mixed; boundary="------------8585C31DD5A6FA609D92FEA6" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------8585C31DD5A6FA609D92FEA6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/28/20 5:32 PM, Michael Heerdegen wrote: > Now stuff is already in the repo, it's inconvenient to review, I took the trouble of retrieving all changes to the emacs-27 documentation since this exercise started, discarding the irrelevant changes, with the result being the attached diff. This should make the new material more convenient to review. Of course this is not a complete substitute for reviewing what's in the manual now, as I could have well missed some stuff that needs changing. --------------8585C31DD5A6FA609D92FEA6 Content-Type: text/x-patch; charset=UTF-8; name="constants.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="constants.diff" diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi index 66aa97e20a..ea16d9ef15 100644 --- a/doc/lispintro/emacs-lisp-intro.texi +++ b/doc/lispintro/emacs-lisp-intro.texi @@ -7317,11 +7317,21 @@ setcar works is to experiment. We will start with the @code{setcar} function. @need 1200 +@cindex constant lists +@cindex mutable lists First, we can make a list and then set the value of a variable to the -list, using the @code{setq} function. Here is a list of animals: +list, using the @code{setq} special form. Because we intend to use +@code{setcar} to change the list, this @code{setq} should not use the +quoted form @code{'(antelope giraffe lion tiger)}, as that would yield +a list that is part of the program and bad things could happen if we +tried to change part of the program while running it. Generally +speaking an Emacs Lisp program's components should be constant (or +unchanged) while the program is running. So we instead construct an +animal list that is @dfn{mutable} (or changeable) by using the +@code{list} function, as follows: @smallexample -(setq animals '(antelope giraffe lion tiger)) +(setq animals (list 'antelope 'giraffe 'lion 'tiger)) @end smallexample @noindent @@ -7398,7 +7408,7 @@ setcdr domesticated animals by evaluating the following expression: @smallexample -(setq domesticated-animals '(horse cow sheep goat)) +(setq domesticated-animals (list 'horse 'cow 'sheep 'goat)) @end smallexample @need 1200 @@ -8846,7 +8856,7 @@ kill-new function @smallexample @group -(setq trees '(maple oak pine birch)) +(setq trees (list 'maple 'oak 'pine 'birch)) @result{} (maple oak pine birch) @end group @@ -9366,7 +9376,7 @@ cons & search-fwd Review @smallexample @group -(setq triple '(1 2 3)) +(setq triple (list 1 2 3)) (setcar triple '37) diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi index 8be8307c75..ec76e83db1 100644 --- a/doc/lispref/edebug.texi +++ b/doc/lispref/edebug.texi @@ -858,7 +858,7 @@ Printing in Edebug Here is an example of code that creates a circular structure: @example -(setq a '(x y)) +(setq a (list 'x 'y)) (setcar a a) @end example diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi index cfd96f7aa6..bba1b63115 100644 --- a/doc/lispref/elisp.texi +++ b/doc/lispref/elisp.texi @@ -297,6 +297,7 @@ Top * Circular Objects:: Read syntax for circular structure. * Type Predicates:: Tests related to types. * Equality Predicates:: Tests of equality between any two objects. +* Constants and Mutability:: Whether an object's value can change. Programming Types diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi index cd45c8df03..baddce4d9c 100644 --- a/doc/lispref/eval.texi +++ b/doc/lispref/eval.texi @@ -158,6 +158,12 @@ Self-Evaluating Forms @end group @end example + A self-evaluating form yields constant conses, vectors and strings, and you +should not attempt to modify their contents via @code{setcar}, @code{aset} or +similar operations. The Lisp interpreter might unify the constants +yielded by your program's self-evaluating forms, so that these +constants might share structure. @xref{Constants and Mutability}. + It is common to write numbers, characters, strings, and even vectors in Lisp code, taking advantage of the fact that they self-evaluate. However, it is quite unusual to do this for types that lack a read @@ -558,6 +564,8 @@ Quoting @defspec quote object This special form returns @var{object}, without evaluating it. +The returned value is a constant, and should not be modified. +@xref{Constants and Mutability}. @end defspec @cindex @samp{'} for quoting @@ -598,6 +606,12 @@ Quoting @end group @end example + Although the expressions @code{(list '+ 1 2)} and @code{'(+ 1 2)} +both yield lists equal to @code{(+ 1 2)}, the former yields a +freshly-minted mutable list whereas the latter yields a constant list +built from conses that may be shared with other constants. +@xref{Constants and Mutability}. + Other quoting constructs include @code{function} (@pxref{Anonymous Functions}), which causes an anonymous lambda expression written in Lisp to be compiled, and @samp{`} (@pxref{Backquote}), which is used to quote @@ -695,6 +709,9 @@ Backquote @end group @end example +If a subexpression of a backquote construct has no substitutions or +splices, it acts like @code{quote} in that it yields constant conses, +vectors and strings that should not be modified. @node Eval @section Eval diff --git a/doc/lispref/keymaps.texi b/doc/lispref/keymaps.texi index fd269d520c..1e81fb1dc5 100644 --- a/doc/lispref/keymaps.texi +++ b/doc/lispref/keymaps.texi @@ -1441,10 +1441,10 @@ Changing Key Bindings @smallexample @group -(setq map '(keymap - (?1 . olddef-1) - (?2 . olddef-2) - (?3 . olddef-1))) +(setq map (list 'keymap + (cons ?1 olddef-1) + (cons ?2 olddef-2) + (cons ?3 olddef-1))) @result{} (keymap (49 . olddef-1) (50 . olddef-2) (51 . olddef-1)) @end group diff --git a/doc/lispref/lists.texi b/doc/lispref/lists.texi index 27fa5385e3..ea44e01f48 100644 --- a/doc/lispref/lists.texi +++ b/doc/lispref/lists.texi @@ -866,10 +866,15 @@ List Variables @node Modifying Lists @section Modifying Existing List Structure @cindex destructive list operations +@cindex mutable lists You can modify the @sc{car} and @sc{cdr} contents of a cons cell with the primitives @code{setcar} and @code{setcdr}. These are destructive operations because they change existing list structure. +Destructive operations should be applied only to mutable lists, +that is, lists constructed via @code{cons}, @code{list} or similar +operations. Lists created by quoting are constants and should not be +changed by destructive operations. @xref{Constants and Mutability}. @cindex CL note---@code{rplaca} vs @code{setcar} @quotation @@ -906,7 +911,7 @@ Setcar @example @group -(setq x '(1 2)) +(setq x (list 1 2)) ; @r{Create a mutable list.} @result{} (1 2) @end group @group @@ -926,8 +931,8 @@ Setcar @example @group -;; @r{Create two lists that are partly shared.} -(setq x1 '(a b c)) +;; @r{Create two mutable lists that are partly shared.} +(setq x1 (list 'a 'b 'c)) @result{} (a b c) (setq x2 (cons 'z (cdr x1))) @result{} (z b c) @@ -1017,11 +1022,11 @@ Setcdr @example @group -(setq x '(1 2 3)) +(setq x (list 1 2 3)) ; @r{Create a mutable list.} @result{} (1 2 3) @end group @group -(setcdr x '(4)) +(setcdr x '(4)) ; @r{Modify the list's tail to be a constant list.} @result{} (4) @end group @group @@ -1037,7 +1042,7 @@ Setcdr @example @group -(setq x1 '(a b c)) +(setq x1 (list 'a 'b 'c)) @result{} (a b c) (setcdr x1 (cdr (cdr x1))) @result{} (c) @@ -1069,7 +1074,7 @@ Setcdr @example @group -(setq x1 '(a b c)) +(setq x1 (list 'a 'b 'c)) @result{} (a b c) (setcdr x1 (cons 'd (cdr x1))) @result{} (d b c) @@ -1130,11 +1135,11 @@ Rearrangement @example @group -(setq x '(1 2 3)) +(setq x (list 1 2 3)) ; @r{Create a mutable list.} @result{} (1 2 3) @end group @group -(nconc x '(4 5)) +(nconc x '(4 5)) ; @r{Modify the list's tail to be a constant list.} @result{} (1 2 3 4 5) @end group @group @@ -1150,7 +1155,7 @@ Rearrangement @example @group -(setq x '(1 2 3)) +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group @@ -1163,11 +1168,13 @@ Rearrangement @end group @end example -However, the other arguments (all but the last) must be lists. +However, the other arguments (all but the last) should be mutable lists. -A common pitfall is to use a quoted constant list as a non-last -argument to @code{nconc}. If you do this, your program will change -each time you run it! Here is what happens: +A common pitfall is to use a constant list as a non-last +argument to @code{nconc}. If you do this, the resulting behavior +is undefined. It is possible that your program will change +each time you run it! Here is what might happen (though this +is not guaranteed to happen): @smallexample @group @@ -1270,7 +1277,7 @@ Sets And Lists @example @group -(setq sample-list '(a b c (4))) +(setq sample-list (list 'a 'b 'c '(4))) @result{} (a b c (4)) @end group @group @@ -1303,12 +1310,12 @@ Sets And Lists (setq flowers (delq 'rose flowers)) @end example -In the following example, the @code{(4)} that @code{delq} attempts to match -and the @code{(4)} in the @code{sample-list} are not @code{eq}: +In the following example, the @code{(list 4)} that @code{delq} attempts to match +and the @code{(4)} in the @code{sample-list} are @code{equal} but not @code{eq}: @example @group -(delq '(4) sample-list) +(delq (list 4) sample-list) @result{} (a c (4)) @end group @end example @@ -1324,7 +1331,7 @@ Sets And Lists @example @group -(setq sample-list '(a b c a b c)) +(setq sample-list (list 'a 'b 'c 'a 'b 'c)) @result{} (a b c a b c) @end group @group @@ -1349,12 +1356,12 @@ Sets And Lists @example @group -(memql 1.2 '(1.1 1.2 1.3)) ; @r{@code{1.2} and @code{1.2} are @code{eql}.} +(memql 1.2 '(1.1 1.2 1.3)) ; @r{@code{1.2} and @code{1.2} must be @code{eql}.} @result{} (1.2 1.3) @end group @group -(memq 1.2 '(1.1 1.2 1.3)) ; @r{@code{1.2} and @code{1.2} are not @code{eq}.} - @result{} nil +(memq 1.2 '(1.1 1.2 1.3)) ; @r{@code{1.2} and @code{1.2} need not be @code{eq}.} + @result{} nil ; @r{... or it might be @code{(1.2 1.3)}.} @end group @end example @end defun @@ -1373,11 +1380,11 @@ Sets And Lists @example @group -(member '(2) '((1) (2))) ; @r{@code{(2)} and @code{(2)} are @code{equal}.} +(member (list 2) '((1) (2))) ; @r{@code{(list 2)} and @code{(2)} are @code{equal}.} @result{} ((2)) @end group @group -(memq '(2) '((1) (2))) ; @r{@code{(2)} and @code{(2)} are not @code{eq}.} +(memq (list 2) '((1) (2))) ; @r{@code{(list 2)} and @code{(2)} are not @code{eq}.} @result{} nil @end group @group @@ -1407,7 +1414,7 @@ Sets And Lists @example @group -(setq l '((2) (1) (2))) +(setq l (list '(2) '(1) '(2))) (delete '(2) l) @result{} ((1)) l @@ -1416,7 +1423,7 @@ Sets And Lists ;; @r{write @code{(setq l (delete '(2) l))}.} @end group @group -(setq l '((2) (1) (2))) +(setq l (list '(2) '(1) '(2))) (delete '(1) l) @result{} ((2) (2)) l @@ -1619,7 +1626,7 @@ Association Lists ("compound leaves" . horsechestnut))) (assq "simple leaves" leaves) - @result{} nil + @result{} @r{Unspecified; might be @code{nil} or non-@code{nil}.} (assoc "simple leaves" leaves) @result{} ("simple leaves" . oak) @end smallexample @@ -1759,7 +1766,7 @@ Association Lists than looking at the saved value of @var{alist}. @example -(setq alist '((foo 1) (bar 2) (foo 3) (lose 4))) +(setq alist (list '(foo 1) '(bar 2) '(foo 3) '(lose 4))) @result{} ((foo 1) (bar 2) (foo 3) (lose 4)) (assq-delete-all 'foo alist) @result{} ((bar 2) (lose 4)) @@ -1926,7 +1933,7 @@ Plist Access in the place where you got @var{plist}. For example, @example -(setq my-plist '(bar t foo 4)) +(setq my-plist (list 'bar t 'foo 4)) @result{} (bar t foo 4) (setq my-plist (plist-put my-plist 'foo 69)) @result{} (bar t foo 69) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 1c4e7e4d4e..1d5b2c690f 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -46,6 +46,10 @@ Lisp Data Types Lisp variables can only take on values of a certain type. @xref{Variables with Restricted Values}.) + Some Lisp objects are @dfn{constant}: their values should never change. +Others are @dfn{mutable}: their values can be changed via destructive +operations that involve side effects. + This chapter describes the purpose, printed representation, and read syntax of each of the standard types in GNU Emacs Lisp. Details on how to use these types can be found in later chapters. @@ -59,6 +63,7 @@ Lisp Data Types * Circular Objects:: Read syntax for circular structure. * Type Predicates:: Tests related to types. * Equality Predicates:: Tests of equality between any two objects. +* Constants and Mutability:: Whether an object's value can change. @end menu @node Printed Representation @@ -2373,3 +2378,52 @@ Equality Predicates @end group @end example @end defun + +@node Constants and Mutability +@section Constants and Mutability +@cindex constants +@cindex mutable objects + + Some Lisp objects are constant: their values should never change +during a single execution of Emacs running well-behaved Lisp code. +For example, you can create a new integer by calculating one, but you +cannot modify the value of an existing integer. + + Other Lisp objects are mutable: it is safe to change their values +via destructive operations involving side effects. For example, an +existing marker can be changed by moving the marker to point to +somewhere else. + + Although all numbers are constants and all markers are +mutable, some types contain both constant and mutable members. These +types include conses, vectors, strings, and symbols. For example, the string +literal @code{"aaa"} yields a constant string, whereas the function +call @code{(make-string 3 ?a)} yields a mutable string that can be +changed via later calls to @code{aset}. + + A mutable object can become constant if it is part of an expression +that is evaluated. The reverse does not occur: constant objects +should stay constant. + + Trying to modify a constant variable signals an error +(@pxref{Constant Variables}). +A program should not attempt to modify other types of constants because the +resulting behavior is undefined: the Lisp interpreter might or might +not detect the error, and if it does not detect the error the +interpreter can behave unpredictably thereafter. Another way to put +this is that although mutable objects are safe to change and constant +variables reliably prevent attempts to change them, other constants +are not safely mutable: if a misbehaving program tries to change such a +constant then the constant's value might actually change, or the +program might crash or worse. This problem occurs +with types that have both constant and mutable members, and that have +mutators like @code{setcar} and @code{aset} that are valid on mutable +objects but hazardous on constants. + + When the same constant occurs multiple times in a program, the Lisp +interpreter might save time or space by reusing existing constants or +constant components. For example, @code{(eq "abc" "abc")} returns +@code{t} if the interpreter creates only one instance of the string +constant @code{"abc"}, and returns @code{nil} if it creates two +instances. Lisp programs should be written so that they work +regardless of whether this optimization is in use. diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi index d89aa31e4c..1cb0d05cc7 100644 --- a/doc/lispref/sequences.texi +++ b/doc/lispref/sequences.texi @@ -183,11 +183,11 @@ Sequence Functions @example @group -(setq bar '(1 2)) +(setq bar (list 1 2)) ; @r{Create a mutable list.} @result{} (1 2) @end group @group -(setq x (vector 'foo bar)) +(setq x (vector 'foo bar)) ; @r{Create a mutable vector.} @result{} [foo (1 2)] @end group @group @@ -278,7 +278,7 @@ Sequence Functions @example @group -(setq x '(a b c)) +(setq x (list 'a 'b 'c)) ; @r{Create a mutable list.} @result{} (a b c) @end group @group @@ -320,7 +320,7 @@ Sequence Functions For the vector, it is even simpler because you don't need setq: @example -(setq x [1 2 3 4]) +(setq x (copy-sequence [1 2 3 4])) ; @r{Create a mutable vector.} @result{} [1 2 3 4] (nreverse x) @result{} [4 3 2 1] @@ -330,7 +330,7 @@ Sequence Functions Note that unlike @code{reverse}, this function doesn't work with strings. Although you can alter string data by using @code{aset}, it is strongly -encouraged to treat strings as immutable. +encouraged to treat strings as immutable even when they are mutable. @end defun @@ -374,7 +374,7 @@ Sequence Functions @example @group -(setq nums '(1 3 2 6 5 4 0)) +(setq nums (list 1 3 2 6 5 4 0)) ; @r{Create a mutable list.} @result{} (1 3 2 6 5 4 0) @end group @group @@ -1228,7 +1228,7 @@ Array Functions @example @group -(setq w [foo bar baz]) +(setq w (vector 'foo 'bar 'baz)) ; @r{Create a mutable vector.} @result{} [foo bar baz] (aset w 0 'fu) @result{} fu @@ -1237,7 +1237,8 @@ Array Functions @end group @group -(setq x "asdfasfd") +;; @r{@code{copy-sequence} creates a mutable string.} +(setq x (copy-sequence "asdfasfd")) @result{} "asdfasfd" (aset x 3 ?Z) @result{} 90 @@ -1246,6 +1247,10 @@ Array Functions @end group @end example +The @var{array} should be mutable; that is, it should not be a constant, +such as the constants created via quoting or via self-evaluating forms. +@xref{Constants and Mutability}. + If @var{array} is a string and @var{object} is not a character, a @code{wrong-type-argument} error results. The function converts a unibyte string to multibyte if necessary to insert a character. @@ -1257,7 +1262,8 @@ Array Functions @example @group -(setq a [a b c d e f g]) +;; @r{Create a mutable vector and then fill it with zeros.} +(setq a (copy-sequence [a b c d e f g])) @result{} [a b c d e f g] (fillarray a 0) @result{} [0 0 0 0 0 0 0] @@ -1265,7 +1271,8 @@ Array Functions @result{} [0 0 0 0 0 0 0] @end group @group -(setq s "When in the course") +;; @r{Create a mutable string and then fill it with "-".} +(setq s (copy-sequence "When in the course")) @result{} "When in the course" (fillarray s ?-) @result{} "------------------" @@ -1302,7 +1309,9 @@ Vectors A vector, like a string or a number, is considered a constant for evaluation: the result of evaluating it is the same vector. This does not evaluate or even examine the elements of the vector. -@xref{Self-Evaluating Forms}. +@xref{Self-Evaluating Forms}. Vectors written with square brackets +are constants and should not be modified via @code{aset} or other +destructive operations. @xref{Constants and Mutability}. Here are examples illustrating these principles: diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi index 14cabc5d79..a4c9c2549c 100644 --- a/doc/lispref/strings.texi +++ b/doc/lispref/strings.texi @@ -51,10 +51,8 @@ String Basics operate on them with the general array and sequence functions documented in @ref{Sequences Arrays Vectors}. For example, you can access or change individual characters in a string using the functions @code{aref} -and @code{aset} (@pxref{Array Functions}). However, note that -@code{length} should @emph{not} be used for computing the width of a -string on display; use @code{string-width} (@pxref{Size of Displayed -Text}) instead. +and @code{aset} (@pxref{Array Functions}). However, you should not +try to change the contents of constant strings (@pxref{Modifying Strings}). There are two text representations for non-@acronym{ASCII} characters in Emacs strings (and in buffers): unibyte and multibyte. @@ -89,6 +87,9 @@ String Basics for information about the syntax of characters and strings. @xref{Non-ASCII Characters}, for functions to convert between text representations and to encode and decode character codes. +Also, note that @code{length} should @emph{not} be used for computing +the width of a string on display; use @code{string-width} (@pxref{Size +of Displayed Text}) instead. @node Predicates for Strings @section Predicates for Strings @@ -380,6 +381,11 @@ Modifying Strings @cindex modifying strings @cindex string modification + You can alter the contents of a mutable string via operations +described in this section. However, you should not try to use these +operations to alter the contents of a constant string. +@xref{Constants and Mutability}. + The most basic way to alter the contents of an existing string is with @code{aset} (@pxref{Array Functions}). @code{(aset @var{string} @var{idx} @var{char})} stores @var{char} into @var{string} at index @@ -591,7 +597,7 @@ Text Comparison @example @group -(sort '("11" "12" "1 1" "1 2" "1.1" "1.2") 'string-collate-lessp) +(sort (list "11" "12" "1 1" "1 2" "1.1" "1.2") 'string-collate-lessp) @result{} ("11" "1 1" "1.1" "12" "1 2" "1.2") @end group @end example @@ -608,7 +614,7 @@ Text Comparison @example @group -(sort '("11" "12" "1 1" "1 2" "1.1" "1.2") +(sort (list "11" "12" "1 1" "1 2" "1.1" "1.2") (lambda (s1 s2) (string-collate-lessp s1 s2 "POSIX"))) @result{} ("1 1" "1 2" "1.1" "1.2" "11" "12") @end group --------------8585C31DD5A6FA609D92FEA6-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 02:48: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, dgutov@yandex.ru, drew.adams@oracle.com Reply-To: rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158830127820070 (code B ref 40671); Fri, 01 May 2020 02:48:02 +0000 Received: (at 40671) by debbugs.gnu.org; 1 May 2020 02:47:58 +0000 Received: from localhost ([127.0.0.1]:48040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jULiJ-0005DO-K1 for submit@debbugs.gnu.org; Thu, 30 Apr 2020 22:47:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jULiI-0005DB-AQ for 40671@debbugs.gnu.org; Thu, 30 Apr 2020 22:47:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34971) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jULiA-0008JX-B4; Thu, 30 Apr 2020 22:47:34 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jULi8-0007N5-QW; Thu, 30 Apr 2020 22:47:33 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: (message from Paul Eggert on Wed, 29 Apr 2020 09:18:20 -0700) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> Message-Id: Date: Thu, 30 Apr 2020 22:47:32 -0400 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] To a purist, the vagueness about what happens to Emacs if you modify code at the wrong time may seem intolerable. If there were an easy and painless way to implement well-defined behavior, it might be worth doing so. But there isn't. This isn't a big difficulty in practice. It isn't worth sacrificing anything that matters. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 03:05: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 To: Drew Adams , Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671-done@debbugs.gnu.org Received: via spool by 40671-done@debbugs.gnu.org id=D40671.158830225021586 (code D ref 40671); Fri, 01 May 2020 03:05:01 +0000 Received: (at 40671-done) by debbugs.gnu.org; 1 May 2020 03:04:10 +0000 Received: from localhost ([127.0.0.1]:48053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jULyE-0005c6-25 for submit@debbugs.gnu.org; Thu, 30 Apr 2020 23:04:10 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:40662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jULyC-0005bu-Be for 40671-done@debbugs.gnu.org; Thu, 30 Apr 2020 23:04:09 -0400 Received: by mail-wm1-f54.google.com with SMTP id u16so4878794wmc.5 for <40671-done@debbugs.gnu.org>; Thu, 30 Apr 2020 20:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sQhWf2LMhjftRLorBCr35IcjQFndvGKr2I9Z6iTmxSE=; b=YQIXvOG7P/ThqDy/xrKrzER0u8sd/YWtWoryRYsNkd6PnPSR3GyN1NlNZaV8WknR9K ilHiwXaPt5VmmTnypnfZIoJHHWg07yw0dHNtNm5fCSkuOhokZTaJclo7K5V8nwHSPPxJ cD/oow+G6vsJo8Y3Iws4hhJ4Fmut9j8uKC65Ddymh2Siigydy+mI9+n5LF0ysHzIK4wx TnUxcapQbsIp6Xa5d26CxwN2YTuwqz1j4n5VVmSmauAVKDBYiSVensB5zmeXY1fB4fFC JwNae6PukrZNbpQCEPQBn67jX1GWp+GjcjjukKpS1OKzHD2SUiFmVl3G60DHBLXw01/Y /uTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sQhWf2LMhjftRLorBCr35IcjQFndvGKr2I9Z6iTmxSE=; b=BM/AKAWJUYLLMA5tTL7eyGrAgbJs5OipOKckRetIlp0kxHaO4ZvER5259V6y/Jievg V8pjkMYWOYuiQs/CAanFnYRM66tAefLXXnZYTPo5G0zfYDRgKBSt8gaClnKZnXhR2ep1 b1Xtc1sG++A52R0fqecUvXgwLWpJBCleEyVQnreprdfp4+Ch7af9gbLV2rDIpwgSleJN 4mEPE570AIn/1cz0tug3f1THSMWVP/kSChkQIdeyW/7iwQam4sprpi2LuxE2CgPyAByH QIRSYeGyy8/D95ZPVcpL6PTRvfv+SYPpYbCceLCWceuGwbsl3aop247CXhk44PW093z8 lFCw== X-Gm-Message-State: AGi0PuZ4h43+XMHBmc/+2gR2EPdvzDDdMAYSE9YBhYn8L4hI+KOFrC99 b/uixJSQ/Jppjj/texdHK6WNNXjojls= X-Google-Smtp-Source: APiQypItFrOw0/wNNRzLL/Yo2CsnszW0PBoGBACxKnWCrWoBbT76k0IIpeSi4tHCEmopWDpzz7q+Qg== X-Received: by 2002:a1c:7212:: with SMTP id n18mr1783154wmc.53.1588302242166; Thu, 30 Apr 2020 20:04:02 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id v131sm2169671wmb.19.2020.04.30.20.04.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 20:04:01 -0700 (PDT) References: <87v9lzmdrw.fsf@laposte.net> From: Dmitry Gutov Message-ID: <08c3b9ad-9c36-9dac-7f23-37886a034c0e@yandex.ru> Date: Fri, 1 May 2020 06:03:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 19.04.2020 00:54, Drew Adams wrote: > It's about code that always creates new list > structure, versus code that might create new > list structure only sometimes (e.g. the first > time it's encountered). Could we call them "interned values"? Like "interned strings" in some programming languages. And then say "don't try to modify them please". The "sometimes" aspect is a semantic snag, but it's certainly better than calling them constant. "literal values" is also an option, but that definition seems limiting. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 03:15: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158830284322437 (code B ref 40671); Fri, 01 May 2020 03:15:01 +0000 Received: (at 40671) by debbugs.gnu.org; 1 May 2020 03:14:03 +0000 Received: from localhost ([127.0.0.1]:48060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUM7n-0005pp-1g for submit@debbugs.gnu.org; Thu, 30 Apr 2020 23:14:03 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:38238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUM7l-0005pD-OO for 40671@debbugs.gnu.org; Thu, 30 Apr 2020 23:14:02 -0400 Received: by mail-wr1-f41.google.com with SMTP id x17so10012548wrt.5 for <40671@debbugs.gnu.org>; Thu, 30 Apr 2020 20:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yjj+5/gdM90z/GTZpn6+XYsUeZ3pno85GuiarCtj56s=; b=CiJQBjmeBW8GbyW6bV461NTn/XYBk/1I4Bj2YQdlm9oE+4ysriciMXJHX9hdDGoKRC 1ByUTgSri64QQXNFGsZuWDPL/FtBaXHnc2uAXSs5S6FFE3frKXIROfFce7AGTYENQqZK S4+3mIRtv22lpaPu9SI4ZnYjYi/a7IKi+O8KwW8k84q/Y57pdKqnK5QVEuH4BSd3c9nw 2JskAsmh4msjKMqb+eLOzTvnqa3H9iOFViLxJl3fRt94PlDXXtoarcdLGN6r+3CYqrkM IMzm1iQgdKMuACW9NE5qlfwdm0EbIR+rHUJ7R+Wty8TdUos9UrgL0N9x3jwzpVTZ9m45 gUkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yjj+5/gdM90z/GTZpn6+XYsUeZ3pno85GuiarCtj56s=; b=GmTqueq/GlY41i3RkTM8YlQ1Lzc1n1bruYEblU8a1bX1XmnlT0Y7iQVTHs6vcszpXj WDJIycGwJMzta4eQTWm251GV8lMjXn/OUIxvW4/QID1C44XWPMUiaWgvp2nFhIC4wYrV +rIw058viGX9XFqEK72Y+WKwNXYJpJCkZcj11BHqGc67UF0cABILBdDdQC9rJVTXQhLu GKVekLRP7R2vti7IQEKOS85kUtdezOxryIdwzXqYFt2gs8g2W9S/u+HpWyGfP4fJJtQ1 t4bpCMiOAN8Ek7FN5zjv/s/v5Gl+xSMbppAhegnYQE2d+NQeHSREO0fKfOqV60E6G7v3 TTWw== X-Gm-Message-State: AGi0PuYfImJS1pSNEarsebkG90MdHZIyWpnLwf1VmyA/Fw5WwMX9LYDD 2iA1uo/Ftxj4XWx5hnulnk4= X-Google-Smtp-Source: APiQypLkmlZqiumVuRl5zWKpN8la61r9kquV1+JsoVb4kMbf1JTECkXb1F4dX3nA7G5FpU8+QABKSg== X-Received: by 2002:a5d:6647:: with SMTP id f7mr1907224wrw.41.1588302835840; Thu, 30 Apr 2020 20:13:55 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id l6sm2475257wrb.75.2020.04.30.20.13.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 20:13:55 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> From: Dmitry Gutov Message-ID: <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> Date: Fri, 1 May 2020 06:13:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 29.04.2020 04:38, Paul Eggert wrote: > On 4/28/20 5:55 PM, Drew Adams wrote: >> You're_not_ using the language that's used for Common Lisp. > In what sense does the language differ? Here's a quote from CLtL2 (page 115): > > "it is an error to destructively modify any object that appears as a constant > in executable code, whether within a 'quote' special form or as > a self-evaluating form." As Drew pointed out (and if I understood this correctly), the above specification leads to implementations that do raise an error when someone tried to modify such a value. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 05:18: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 To: Dmitry Gutov , Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671-done@debbugs.gnu.org Received: via spool by 40671-done@debbugs.gnu.org id=D40671.15883102284180 (code D ref 40671); Fri, 01 May 2020 05:18:01 +0000 Received: (at 40671-done) by debbugs.gnu.org; 1 May 2020 05:17:08 +0000 Received: from localhost ([127.0.0.1]:48082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUO2u-00015M-EP for submit@debbugs.gnu.org; Fri, 01 May 2020 01:17:08 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:44956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUO2r-00014n-QQ for 40671-done@debbugs.gnu.org; Fri, 01 May 2020 01:17:06 -0400 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 0415DLpp124604; Fri, 1 May 2020 05:16:45 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=PDXEAqG9aLMvisXoNSN/Hh80gvDqKWjcNF70X+joWd0=; b=f5Y0Kwd/ImKK2AJ+Rp78PukQw2aw94iW6WPcJjLVE1nNaKroo2WtWzcqOW+38Ik30gXe R0uq5tD//wu8+LXC3VnPaXaHYF+mcKyel/wQKhTdiSq6JfCfMYL6GUsx91sxjZicYf8A yK813thNn5IsMHTr2wH9neMagq5KoC7zMFPEW9ZhArQ3JCYIugPL+XPJRQhL+M98BanY Cq9SUoDh0ZBKvW1kVuBVVxIt6uQlU20BAOoUg78lfZxBLvoSLY/Ktn4XGYaV52xJ/SvA 1Xg9tZz9dPnjmvRn4lllcCShctHldkRxJgSllZNr0MeZl9xRfCsk3QJI+Q/aXZx5+WP5 vg== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 30r7f3guds-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 May 2020 05:16:45 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0415D0ro087153; Fri, 1 May 2020 05:16:44 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 30r7f9a7p8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 May 2020 05:16:44 +0000 Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0415GhJp018363; Fri, 1 May 2020 05:16:43 GMT MIME-Version: 1.0 Message-ID: <89f0fa3b-5ba7-41d1-82d2-2aea8d9a6148@default> Date: Thu, 30 Apr 2020 22:16:42 -0700 (PDT) From: Drew Adams References: <87v9lzmdrw.fsf@laposte.net> <08c3b9ad-9c36-9dac-7f23-37886a034c0e@yandex.ru> In-Reply-To: <08c3b9ad-9c36-9dac-7f23-37886a034c0e@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9607 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=18 phishscore=0 malwarescore=0 mlxscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005010036 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9607 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 suspectscore=18 phishscore=0 mlxlogscore=999 impostorscore=0 spamscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005010036 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > It's about code that always creates new list > > structure, versus code that might create new > > list structure only sometimes (e.g. the first > > time it's encountered). >=20 > Could we call them "interned values"? Like "interned strings" in some > programming languages. And then say "don't try to modify them please". >=20 > The "sometimes" aspect is a semantic snag, but it's certainly better > than calling them constant. >=20 > "literal values" is also an option, but that definition seems limiting. You're replying to a message of mine from a while back. I agree with the limitation or difficulty of communicating the "sometimes" aspect. And I agree that the message for users should be "don't try to modify them" (even though the "them" isn't detailed). My own opinion is to avoid mention of any such name: constant, literal, interned this-or-that. Better to keep it vague, and just sketch the problem and say that the behavior is undefined. IMO, the message for users for the quoted-list gotcha should be to not assume that code that has a quoted list in it creates a new list whenever you might think that that code (Lisp source or byte-compiled) gets evaluated. `quote' returns its arg unevaluated, but it's not always clear by looking at the source code just when or how many times a quoted list might get evaluated. That's undefined, so assume nothing about it. In particular, the behavior can differ for the same source code, depending on whether it's interpreted or byte-compiled. A simple example could suffice, to make that point. If it helps, we can also say, for the example, that the source-code quoted list might, in effect, get replaced by its value when it's read or byte-compiled, so the same cons cells (not new list structure) might get reused each time the resulting code gets evaluated. And because of that possibility you're advised not to try to modify such a list. Yes, there are other examples of the problem, besides quoted lists. Like the Common Lisp doc, we could list some of them, without giving more examples or going into detail. Or we could give a second simple example, perhaps with a string literal. What's important, I think, is to (1) get across the general idea/problem, (2) give some idea how to recognize situations where the gotcha can arise, and make clear that you cannot depend on the behavior. There's no prevention of the gotcha, e.g. by raising an error systematically. You just have to learn to recognize the possibility of trying to modify something that may have become, at some point, effectively unmodifiable - and not do that. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 05:19: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 To: Dmitry Gutov , Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15883103064308 (code B ref 40671); Fri, 01 May 2020 05:19:02 +0000 Received: (at 40671) by debbugs.gnu.org; 1 May 2020 05:18:26 +0000 Received: from localhost ([127.0.0.1]:48087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUO49-00017Q-R0 for submit@debbugs.gnu.org; Fri, 01 May 2020 01:18:26 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:49146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUO48-00017D-Bm for 40671@debbugs.gnu.org; Fri, 01 May 2020 01:18:24 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0415HwAT051078; Fri, 1 May 2020 05:18:09 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=ZBw9E0DTtndwbDqhYRxVq0LjcSFUJ22Ia0okaeM2vNE=; b=YAlLsytXov/ovsm0GgCsmLXH7MATRtD5rkdNgHYtBrH/JarjlZPX0fyPcXdDBwcA08+p fRH7BVwwh34L7MxNc3TC68hwJDRuCUAIyfbDfPaHfjsu9j6yNw9Jr9BIFy/DDFCVK1J0 tbWBye2H8cQK1DlLoap+oNnGJEIDJFZw3jImktpvjKInPLXFh2rCFGyr/R+2afuo4iy+ 7FVFwBoQlOCHbYBMzNgYOo54lxZZ/wzs6wrH1WLKITO24G0985+wvajH6ad4MuCS/gMw EHG4sw0vXh8QLzwoTs1xB3bp46KWqdBCAF4i0bevpRGQKnxm+JOwDSXmS0zvl/7+v92Q cg== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 30r7f80uf6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 May 2020 05:18:09 +0000 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 0415CWov032909; Fri, 1 May 2020 05:16:08 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 30r7f2vbfb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 May 2020 05:16:08 +0000 Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0415Fs4t015452; Fri, 1 May 2020 05:15:54 GMT MIME-Version: 1.0 Message-ID: <47664b27-687f-4d23-bc55-9f3faa7965a9@default> Date: Thu, 30 Apr 2020 22:15:53 -0700 (PDT) From: Drew Adams References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> In-Reply-To: <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9607 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 phishscore=0 adultscore=0 spamscore=0 mlxlogscore=900 bulkscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005010036 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9607 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxlogscore=959 spamscore=0 malwarescore=0 clxscore=1015 phishscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=18 adultscore=0 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005010036 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > >> You're _not_ using the language that's used for Common Lisp. > > In what sense does the language differ? Here's a quote from CLtL2 > (page 115): > > > > "it is an error to destructively modify any object that appears as a > constant > > in executable code, whether within a 'quote' special form or as > > a self-evaluating form." >=20 > As Drew pointed out (and if I understood this correctly), the above > specification leads to implementations that do raise an error when > someone tried to modify such a value. That's my understanding. I believe that wasn't the case for CLTL(1) - there was no such promise or requirement. And I think it's also not the case for Elisp. Like CLTL(1), we should just warn users about the gotcha, since there's no protection from it. To be clear, I'm no expert on CLTL2. I used CL for years before that. The gotcha bit me once, having modified the result of a quoted list - and then someone explained what was happening. It's too easy for a newbie to think only in terms of textual source code being interpreted. It's easy not to realize, as Michael said, that there's the Lisp reader, the interpreter, and the byte-compiler, and each might get a chance to handle a quoted list. And just how they did so was not specified. Presumably, a conformant CL implementation now protects you from this gotcha. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 06:24: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 To: rms@gnu.org Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, dgutov@yandex.ru Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158831422110720 (code B ref 40671); Fri, 01 May 2020 06:24:01 +0000 Received: (at 40671) by debbugs.gnu.org; 1 May 2020 06:23:41 +0000 Received: from localhost ([127.0.0.1]:48127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUP5F-0002mn-KO for submit@debbugs.gnu.org; Fri, 01 May 2020 02:23:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUP5D-0002mZ-S7 for 40671@debbugs.gnu.org; Fri, 01 May 2020 02:23:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38361) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUP57-0007SI-MZ; Fri, 01 May 2020 02:23:29 -0400 Received: from [176.228.60.248] (port=2387 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jUP50-0001tp-LJ; Fri, 01 May 2020 02:23:23 -0400 Date: Fri, 01 May 2020 09:23:10 +0300 Message-Id: <83a72sw4vl.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Richard Stallman on Thu, 30 Apr 2020 22:47:32 -0400) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Richard Stallman > Date: Thu, 30 Apr 2020 22:47:32 -0400 > Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, michael_heerdegen@web.de, > mattiase@acm.org, dgutov@yandex.ru > > To a purist, the vagueness about what happens to Emacs if you modify > code at the wrong time may seem intolerable. If there were an easy > and painless way to implement well-defined behavior, it might be worth > doing so. But there isn't. > > This isn't a big difficulty in practice. It isn't worth sacrificing > anything that matters. I agree, but the practical problem is that we have a couple of purists on board, for whom this is an itch they scratch not too infrequently. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 21:42: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 To: Dmitry Gutov , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158836928230987 (code B ref 40671); Fri, 01 May 2020 21:42:01 +0000 Received: (at 40671) by debbugs.gnu.org; 1 May 2020 21:41:22 +0000 Received: from localhost ([127.0.0.1]:50818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUdP9-00083T-Kg for submit@debbugs.gnu.org; Fri, 01 May 2020 17:41:21 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUdP8-000834-EQ for 40671@debbugs.gnu.org; Fri, 01 May 2020 17:41:06 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E2877160079; Fri, 1 May 2020 14:41:00 -0700 (PDT) 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 mjo2ijw6Ipjv; Fri, 1 May 2020 14:40:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DD7B61600C7; Fri, 1 May 2020 14:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 8wgIuUGtQChA; Fri, 1 May 2020 14:40:59 -0700 (PDT) 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 9236F160079; Fri, 1 May 2020 14:40:59 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Fri, 1 May 2020 14:40:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 4/30/20 8:13 PM, Dmitry Gutov wrote: > On 29.04.2020 04:38, Paul Eggert wrote: >> Here's a quote from CLtL2 (page 115): >> >> "it is an error to destructively modify any object that appears as a constant >> in executable code, whether within a 'quote' special form or as >> a self-evaluating form." > > As Drew pointed out (and if I understood this correctly), the above > specification leads to implementations that do raise an error when someone tried > to modify such a value. Although those implementations conform to the Common Lisp spec, that's because the spec explicitly says such behavior is undefined - which means implementations can signal an error, dump core, or do whatever else they want. See , which uses "should" in the same sense the emacs-27 elisp manual uses "should". Here's a quote: ----- When this book specifies that it "is an error" for some situation to occur, this means that: * No valid Common Lisp program should cause this situation to occur. * If this situation occurs, the effects and results are completely undefined as far as adherence to the Common Lisp specification is concerned. * No Common Lisp implementation is required to detect such an error. Of course, implementors are encouraged to provide for detection of such errors wherever reasonable. This is not to say that some particular implementation might not define the effects and results for such a situation; the point is that no program conforming to the Common Lisp specification may correctly depend on such effects or results. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 21:47: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 To: Dmitry Gutov , Drew Adams , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671-done@debbugs.gnu.org Received: via spool by 40671-done@debbugs.gnu.org id=D40671.158836961031528 (code D ref 40671); Fri, 01 May 2020 21:47:02 +0000 Received: (at 40671-done) by debbugs.gnu.org; 1 May 2020 21:46:50 +0000 Received: from localhost ([127.0.0.1]:50822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUdUg-0008CS-Ct for submit@debbugs.gnu.org; Fri, 01 May 2020 17:46:50 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUdUe-0008CC-BB for 40671-done@debbugs.gnu.org; Fri, 01 May 2020 17:46:48 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C5ADB1600C7; Fri, 1 May 2020 14:46:42 -0700 (PDT) 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 S511iCqlDmql; Fri, 1 May 2020 14:46:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 97C8E160079; Fri, 1 May 2020 14:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 mMZzybDk5iwJ; Fri, 1 May 2020 14:46:40 -0700 (PDT) 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 267F11600C7; Fri, 1 May 2020 14:46:40 -0700 (PDT) References: <87v9lzmdrw.fsf@laposte.net> <08c3b9ad-9c36-9dac-7f23-37886a034c0e@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <7d5b24f9-b739-8160-71eb-3795ad9231c6@cs.ucla.edu> Date: Fri, 1 May 2020 14:46:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <08c3b9ad-9c36-9dac-7f23-37886a034c0e@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/30/20 8:03 PM, Dmitry Gutov wrote: > Could we call them "interned values"? Like "interned strings" in some > programming languages. "Interned" would imply that we're merely deduplicating objects by hashing their contents, which means modifying one deduplicated object modifies them all. But the problem is bigger than that. There are some objects that one simply should not modify, even if they are not deduplicated. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 22:06: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 To: Paul Eggert , Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15883707271099 (code B ref 40671); Fri, 01 May 2020 22:06:02 +0000 Received: (at 40671) by debbugs.gnu.org; 1 May 2020 22:05:27 +0000 Received: from localhost ([127.0.0.1]:50861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUdmh-0000Hf-AG for submit@debbugs.gnu.org; Fri, 01 May 2020 18:05:27 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:34434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUdme-0000HR-S2 for 40671@debbugs.gnu.org; Fri, 01 May 2020 18:05:25 -0400 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 041Lx5wR158487; Fri, 1 May 2020 22:05:15 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=WdEl4y1A8tX2RAHRTJ79uSXSuYxR7bcxHiOIl5hsYko=; b=agWAVoioFL79qvWqZFE0S1Zeg8Eb6xye0ruM0vISjjdUozSE+8d9pNBC/rXk+gBMSmVl xPHZzcYPUqIwcgC3/WVGXe7sI2hFPN4IUdnHieit7NHPkzPMlChKVESAGGl4cRwHuha2 LzMx4l3UtN9YG1LfkVMl4FbBSGHntbadrRbkV5wpgAjgz95tDUGw/K29f44dWlHQQn2f 0mHxhmR3SOVvs9mfu3DlaFvZuhhKZH35AUG5WwXXmYYq0komTAmstxP+hnI4UiGZRgSx 2M23IpiQqoF2ikDgheM8FpLfqS9uYBVjAP4WwO8dKlwgfQE/ZolnQmFREKVi+6uhdKz3 oA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 30r7f3m7dq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 May 2020 22:05:15 +0000 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 041LuXCM129917; Fri, 1 May 2020 22:05:15 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 30r7f53v3a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 May 2020 22:05:15 +0000 Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 041M5CkK021197; Fri, 1 May 2020 22:05:13 GMT MIME-Version: 1.0 Message-ID: <10f088bf-c5d7-4d20-a704-86e4d35b087b@default> Date: Fri, 1 May 2020 15:05:11 -0700 (PDT) From: Drew Adams References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9608 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 phishscore=0 adultscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005010154 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9608 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 suspectscore=1 phishscore=0 mlxlogscore=999 impostorscore=0 spamscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005010154 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > >> Here's a quote from CLtL2 (page 115): > >> > >> "it is an error to destructively modify any object that appears as a > >> constant in executable code, whether within a 'quote' special form or = as > >> a self-evaluating form." > > > > As Drew pointed out (and if I understood this correctly), the above > > specification leads to implementations that do raise an error when > > someone tried to modify such a value. >=20 > Although those implementations conform to the Common Lisp spec, that's > because the spec explicitly says such behavior is undefined - which means > implementations can signal an error, dump core, or do whatever else > they want. > See > /clm/node11.html__;!!GqivPVa7Brio!NeqWMrCFKgi8Ktwdz5aIkeBh_-TPzH- > XiJbWDMeSRu1VKiI70b5LK6Sy2v5CMxaq$ >, which uses > "should" in the same sense the emacs-27 elisp manual uses "should". I stand corrected. I was assuming that the "proposal" I cited had actually been adopted for CLTL2. So CLTL2 is in the same boat as CLTL(1), in the regard relevant to this thread: There is NO systematic raising of an error - no prevention of the gotcha. So what I said about Elisp being like CLTL(1) applies also to CLTL2: We should NOT say that you _cannot_ do XYZ (because you might be able to, and the behavior if you try is undefined). We should instead say that you _should not_. We're still circling, though. But thanks for clarifying that "it's an error" meaning. I misremembered that as meaning that a conformant implementation is required to raise an error. I was thinking/assuming that the cited proposal was in fact adopted as part of the CL definition. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 22: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 To: Drew Adams , Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15883721093247 (code B ref 40671); Fri, 01 May 2020 22:29:01 +0000 Received: (at 40671) by debbugs.gnu.org; 1 May 2020 22:28:29 +0000 Received: from localhost ([127.0.0.1]:50884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUe8z-0000qJ-1m for submit@debbugs.gnu.org; Fri, 01 May 2020 18:28:29 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUe8x-0000q6-Bu for 40671@debbugs.gnu.org; Fri, 01 May 2020 18:28:27 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D46AB160079; Fri, 1 May 2020 15:28:21 -0700 (PDT) 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 UZitHCXksbBU; Fri, 1 May 2020 15:28:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 29BDB1600C7; Fri, 1 May 2020 15:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 2SYtZcUiTaDE; Fri, 1 May 2020 15:28:21 -0700 (PDT) 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 D004A160079; Fri, 1 May 2020 15:28:20 -0700 (PDT) References: <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <10f088bf-c5d7-4d20-a704-86e4d35b087b@default> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Fri, 1 May 2020 15:28:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <10f088bf-c5d7-4d20-a704-86e4d35b087b@default> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/1/20 3:05 PM, Drew Adams wrote: > We should NOT say that you _cannot_ > do XYZ (because you might be able to, and the behavior > if you try is undefined). We should instead say that > you _should not_. That's what the emacs-27 manual does now. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2020 23:38: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 To: Paul Eggert , Drew Adams , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Kevin Vigouroux , 40671-done@debbugs.gnu.org Received: via spool by 40671-done@debbugs.gnu.org id=D40671.15883762359728 (code D ref 40671); Fri, 01 May 2020 23:38:01 +0000 Received: (at 40671-done) by debbugs.gnu.org; 1 May 2020 23:37:15 +0000 Received: from localhost ([127.0.0.1]:50938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUfDX-0002Wq-E4 for submit@debbugs.gnu.org; Fri, 01 May 2020 19:37:15 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:39026) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUfDV-0002We-S0 for 40671-done@debbugs.gnu.org; Fri, 01 May 2020 19:37:14 -0400 Received: by mail-wr1-f47.google.com with SMTP id l18so2911192wrn.6 for <40671-done@debbugs.gnu.org>; Fri, 01 May 2020 16:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YNC1I407dtLsI7ryNxVPie8kYyxEdORcr51r8aTfXTs=; b=VfxV4IDx2slXMRZ9JzFeBA8ax53t+hCBwtTDvAXmhhmEUDkdxgL/6ya5rw3r7NMGSu Xo0miaI2arOWUi5CCEWa7nbVLsjPWqtSVp36f/ID6l1qg/fTx81UbPi5g09by/rKJkYh z2bjvtdGVBgOkG8KfIJRyhnOu08XIDl4f6XfKC53+RBMUlmf/Sr1W+shZ+kKvkyOjfue 2GZurp58Zchk1eGTt4kFhtOAp9x5HkyiectUAlsGCffdfccn1M1xUndKyUAaQvNAIWaL 45WmH8kA8BTtGTTCwdQqICSTugUH6dseewYljoDHKEUmws8qTCd2NOG8ZHtF4B2cR29K GWwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YNC1I407dtLsI7ryNxVPie8kYyxEdORcr51r8aTfXTs=; b=X7aW9TGwV0OkQNXoZassjH71cUqKgtPY/mTaET6QPLRTbOmu2LYgcna8FomWtRdpXn 3rPIT7NUwM3GJOQ2SRqu1pUEoRsIIRaI/51kXU/aM2k9nws/g69q6PdKh6oPFM2ptno+ x/F+J8eW2/3GCKK8lrXky4M+RMW8VV+WzNqnkw8B73uBgIByi/oFKTQNuQnSVFg+g0wd n/NGRCQMPLugYvhnJ0Bqsufo3CgBBB1N8tZQE9DAuMjVRaOaS8xTZxZmTxDIjCnTVblo 5N9GHG1JEmw3wMYzFAyBViSz31za2Pm2QjSTYfa/AnOjSak/TQL1RsMJQr1s0G7aLh4j EuLA== X-Gm-Message-State: AGi0Pub65lGN97Z5RnhUPXhvRVG40iSdoLV7TtSXjn0ZfJg7PSEgp0fD JC/R2loqVssKl5q+Q/fYPexRW5rezXQ= X-Google-Smtp-Source: APiQypKcQY7MO52/KdyxBKSr4INxLvqdm8MuTMXhpW8GdfCu0dixHs0LAlrn6C/TSq7CJot/wd8EXA== X-Received: by 2002:adf:8401:: with SMTP id 1mr6790942wrf.241.1588376227716; Fri, 01 May 2020 16:37:07 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id v7sm1348182wmg.3.2020.05.01.16.37.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2020 16:37:07 -0700 (PDT) References: <87v9lzmdrw.fsf@laposte.net> <08c3b9ad-9c36-9dac-7f23-37886a034c0e@yandex.ru> <7d5b24f9-b739-8160-71eb-3795ad9231c6@cs.ucla.edu> From: Dmitry Gutov Message-ID: <2cf2856d-94b4-851d-0d7f-f30537682b9d@yandex.ru> Date: Sat, 2 May 2020 02:37:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <7d5b24f9-b739-8160-71eb-3795ad9231c6@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02.05.2020 00:46, Paul Eggert wrote: > On 4/30/20 8:03 PM, Dmitry Gutov wrote: >> Could we call them "interned values"? Like "interned strings" in some >> programming languages. > "Interned" would imply that we're merely deduplicating objects by hashing their > contents, which means modifying one deduplicated object modifies them all. But > the problem is bigger than that. There are some objects that one simply should > not modify, even if they are not deduplicated. True. It's just the closest term from other languages I know that I could think of. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2020 01:08: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158838167918210 (code B ref 40671); Sat, 02 May 2020 01:08:01 +0000 Received: (at 40671) by debbugs.gnu.org; 2 May 2020 01:07:59 +0000 Received: from localhost ([127.0.0.1]:50949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUgdL-0004jd-BR for submit@debbugs.gnu.org; Fri, 01 May 2020 21:07:59 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:55897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUgdJ-0004jP-31 for 40671@debbugs.gnu.org; Fri, 01 May 2020 21:07:57 -0400 Received: by mail-wm1-f52.google.com with SMTP id e26so1861969wmk.5 for <40671@debbugs.gnu.org>; Fri, 01 May 2020 18:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mb3Pzf5ystzK8PTmeygZwByo/F9Xwg8j5vttJTy4918=; b=iyhb94Xu8Ec7v48k7YqiQFqRVEts00PDpd4B3Ptp/nhZouK56gqTK0mGR/duEhTXQj xsYd8G6EJ0tHlx9tVKJbQh63/JbBp3QTDbQijP9do26LYs7a53neZd3t49RA7ociNHP6 I9QvLpVmrOLARFx1FAZGdyF4dvpQZ9360RBYh0RPYdMqJwIDCIDWc+Nj8oiWYMq2GIJg DWvwkig4onxxyUYjaeENxpRdkqJL7YocnteDXAtYsTZDD1N+HQyKX91rqHFqjY2BR6Oa WpmYiRHl93Y2ouG1Z4W3cM9Z+xZDzIwPxNYqvRnEEXMD6O3JVKBsAJC5uTIxTgdRyAvs elLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mb3Pzf5ystzK8PTmeygZwByo/F9Xwg8j5vttJTy4918=; b=HfVTqxs9QlJreNyv91lOyfThaT23BSEl/2wq3p4hrOfz8cHu+D+FXVAFU4aAIEIHKQ KGWgtnzn8cocPgmiIXog8TJJ0xY5rNsU3ZSUC0V6NZdo83f9sm5a0mwEjqSE3SNTiCvX FRtMsBkIzTSO96YPlPoIM85BG72VwAmXgePvumV3tr38XolJumKSkFduqyOC5TLx+/Lt Xorc8hsBVd/JW+Iwp0pyyXNtljzaHA6oDl2NJLrlm3C/hKJR7di/vkhZOftHOR5iXg/X TBm1GDHImpoi/f/ZVVpG7B6Sfui4LXe7+3DEDJ/vni9kRug0HWNPVz1zQ/Cp6XBccWjs 1Juw== X-Gm-Message-State: AGi0Pua4/6cOzzy3r90p3xqhiODoSpSaIB/YhKanAi9BPsk0RY5IKFk5 +C3SMKGZ+mFeMXGLZ2VoO5I= X-Google-Smtp-Source: APiQypJZ0WslCdFQXllSTRA8nlx6Ph0nXiG1Ff03G6wUN3Thylwk92RWOI1i1rVULIhDYhlJ7o0x0Q== X-Received: by 2002:a1c:44d7:: with SMTP id r206mr2052636wma.101.1588381671187; Fri, 01 May 2020 18:07:51 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id f83sm1808805wmf.42.2020.05.01.18.07.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2020 18:07:50 -0700 (PDT) References: <530d3597-aaaa-f019-bafa-8229d13e7248@yandex.ru> <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> From: Dmitry Gutov Message-ID: Date: Sat, 2 May 2020 04:07:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02.05.2020 00:40, Paul Eggert wrote: >> As Drew pointed out (and if I understood this correctly), the above >> specification leads to implementations that do raise an error when someone tried >> to modify such a value. > > Although those implementations conform to the Common Lisp spec, that's because > the spec explicitly says such behavior is undefined - which means > implementations can signal an error, dump core, or do whatever else they want. > See , which uses > "should" in the same sense the emacs-27 elisp manual uses "should". I suppose so. > When this book specifies that it "is an error" for some situation to occur, this > means that: > > * No valid Common Lisp program should cause this situation to occur. > > * If this situation occurs, the effects and results are completely undefined as > far as adherence to the Common Lisp specification is concerned. > > * No Common Lisp implementation is required to detect such an error. Of course, > implementors are encouraged to provide for detection of such errors wherever > reasonable. > > This is not to say that some particular implementation might not define the > effects and results for such a situation; the point is that no program > conforming to the Common Lisp specification may correctly depend on such effects > or results. Indeed. I took a longer look around the CLtL, to see how the term "constant" is used there, though. Some phrases: --- ...it is an error to destructively modify any object that appears as a constant in executable code, whether as a self-evaluating form or within a quote special form ...to specify what objects can be in compiled constants... quoted constants in it are similar in this sense to quoted constants in the corresponding source code An object may be used as a quoted constant... Some types of objects, such as streams, are not supported in constants processed by the file compiler. Such objects may not portably appear as constants in code processed with compile-file. The following terms are used throughout this section. The term constant refers to a quoted or self-evaluating constant, not a named constant defined by defconstant. Two objects are similar as a constant if and only if they are both of one of the types listed below and satisfy... Two conses are similar as constants if the values of their respective car and cdr attributes are similar as constants. (Then comes the description of "similar as constants" values being coalesced in compiled code). --- CL's terminology seems fairly old by today's standards, but it looks like they were grasping for words, just as we are now. They very rarely use the phrase "constant objects", however. Instead, it's almost always "objects that appears as a constant [in code]", "object ... used as a quoted constant", "object may not ... appear as constants in code", "objects are similar as a constant". IOW, it's the difference between constant values and constant pointers to [mutable] values. And the users are advised not to change the objects that "appear as constants"/[play the role of constants]/[are the values of constants] in executable code. And there is no juxtaposition of "mutable objects" vs "constant objects" anywhere in there, with "constant" defined like that, which is the part of our new documentation that really got me into this discussion. So the section "Constants and Mutability", even though it has valuable information, could use a full rewrite. And could probably move to end of the "Self-Evaluating Forms" section. I'm also not sure it's a good idea to add too much explanations to the introduction featuring phrases like "a list that is part of the program and bad things could happen if we tried to change part of the program while running it", so I'd keep the changes in the examples (the ones I looked at look sensible), but remove most of the explanations. Moreso that they are using the phrases "mutable values" and "constant values". Some short explanation could say that it's a bad idea to modify a quoted form (and then reference "Self-Evaluating Forms"). I can try to make a patch, but at this point is would consist mostly of deletions. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2020 06:29: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 To: Dmitry Gutov , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158840093126316 (code B ref 40671); Sat, 02 May 2020 06:29:02 +0000 Received: (at 40671) by debbugs.gnu.org; 2 May 2020 06:28:51 +0000 Received: from localhost ([127.0.0.1]:51114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUldr-0006qO-D1 for submit@debbugs.gnu.org; Sat, 02 May 2020 02:28:51 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48356) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUldq-0006qC-9H for 40671@debbugs.gnu.org; Sat, 02 May 2020 02:28:50 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BC036160066; Fri, 1 May 2020 23:28:44 -0700 (PDT) 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 3khhJEQUrFRf; Fri, 1 May 2020 23:28:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8D7DD1600CC; Fri, 1 May 2020 23:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 AJdzBCTfPU1E; Fri, 1 May 2020 23:28:43 -0700 (PDT) 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 416B9160066; Fri, 1 May 2020 23:28:43 -0700 (PDT) References: <60b88f52-c50d-c57a-9ce5-495e6157d36e@cs.ucla.edu> <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <012e8bc3-df4b-3884-4e54-5fe7ef4248cb@cs.ucla.edu> Date: Fri, 1 May 2020 23:28:43 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/1/20 6:07 PM, Dmitry Gutov wrote: > They very rarely use the phrase "constant objects", however. Instead, it's > almost always "objects that appears as a constant [in code]", "object ... used > as a quoted constant", "object may not ... appear as constants in code", > "objects are similar as a constant". We could use similar circumlocutions. Or instead of saying "constant" we could say "unchanging", as distinct from "unchangeable". (It beats "object-that-should-not-be-changed" or "glass object - you changed it, you broke it!". :-) The usual word for this notion is "constant", though. > IOW, it's the difference between constant values and constant pointers to > [mutable] values. I don't see that. A constant (or "unchanging") string is like a mutable string, except you shouldn't change it. There's no sense in CLtL in which a mutable object must be implemented via a pointer to a value whereas a constant must not be implemented that way. > there is no juxtaposition of "mutable objects" vs "constant objects" > anywhere in there Yes, the mutable/immutable terminology revolution happened mostly after CLtL was written. > So the section > "Constants and Mutability", even though it has valuable information, could use a > full rewrite. And could probably move to end of the "Self-Evaluating Forms" > section. Whether an object is constant is distinct from whether it's derived from a self-evaluating form, because one can have constants that were never derived from any self-evaluating form. Any doc rewrite should be careful to keep the two notions distinct, quite plausibily (though not necessarily) in different sections. > I can try to make a patch, but at this point is would consist mostly of deletions. Certainly some stuff could be deleted (the tutorial could be trimmed as you suggest, for example), but we should keep the baby while we're throwing out the bathwater. And if we're using circumlocutions the text is likely to get longer, not shorter. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2020 15:43: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158843415816876 (code B ref 40671); Sat, 02 May 2020 15:43:01 +0000 Received: (at 40671) by debbugs.gnu.org; 2 May 2020 15:42:38 +0000 Received: from localhost ([127.0.0.1]:53723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUuHm-0004O8-0D for submit@debbugs.gnu.org; Sat, 02 May 2020 11:42:38 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:33344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUuHk-0004Nv-71 for 40671@debbugs.gnu.org; Sat, 02 May 2020 11:42:36 -0400 Received: by mail-wr1-f48.google.com with SMTP id h9so5141336wrt.0 for <40671@debbugs.gnu.org>; Sat, 02 May 2020 08:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sjzHWOAshImTAdngIapK9j9vwWiWqbvOh9IsKbs3peI=; b=D9JXrzd4h0l2PkwunJQVTXPLPKcCdsq8LhSSX80byxUIVWJwUQUGKGHa82mEq6xUeF 2cR9Hdx4vsSlRwcAZoSxIbhrJ3qygwLLT55EHze0vvERFnFCrHnh/0/t/bonjdkU9Ou8 3qDjxxGm11gu6odZDwXkHuJGR6hJ9d5cTiN2awjNe4nrfpEA3LGYZBNsW7/bEJr6kRPX NvC2kM6Hs58NwI2ESl5ouOECJGCUmsuhnjZOQ7ZnuWRDKNYFlB2zk2gKCKF583CZubdB 4T9H0FqgbG/g5Nmi1r2/+NiTxns38INKuaMH9C1AP+zWuY4YTsan1FSE3yjXhcjYhirs dbLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sjzHWOAshImTAdngIapK9j9vwWiWqbvOh9IsKbs3peI=; b=YdqUXsqtxk17TOAJGVKGXlqrzmTxz6xPyXQEW4G+12Pzq6JIyjivlngHtCUTf94tiI XzK1tNYdxBEJfxhwJlyHhnZvrlpqsWZFpbu53HBIyBK4jijyvLBY7yPooS/m9FnA1kJk a9Bg4WElKJihui5Yztp2AXyYHE7pChIqnRBW3NDzMbFag34jNT/v7lKQOWru8kw7Zijq PzGeIxisR9uf1SiVFPgnPslcPGSm0rte1NYa2703K26/vubCsbuIA1Ik5ZTFhGnza03/ /YNB/IyPro2drhYJvdfFXX7j9ksGESaZgGR4i+UwQz+bnPT0oCpDNH2EveC0p8KbKasR 37KQ== X-Gm-Message-State: AGi0Puaps1XcPNqeBbpB7LI7HYQSmAxVep1wdOSX1CfmDr/k3DFa45tc muLtQlJf9e/DNWhXrFKosSk= X-Google-Smtp-Source: APiQypKRWWpRvO441wy9X0R6OWA34vk6aRJFxDwND35TXiqAXL5EDDMcQPSVRdqjzDtihnG6CYndOQ== X-Received: by 2002:a5d:49cb:: with SMTP id t11mr9737232wrs.91.1588434150274; Sat, 02 May 2020 08:42:30 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 36sm10181989wrc.35.2020.05.02.08.42.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 May 2020 08:42:29 -0700 (PDT) References: <0721d8c1-4fe3-335c-7dbc-171487cb648a@yandex.ru> <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <012e8bc3-df4b-3884-4e54-5fe7ef4248cb@cs.ucla.edu> From: Dmitry Gutov Message-ID: <37a54ac2-da80-ca35-9c01-38c8e12a4b5f@yandex.ru> Date: Sat, 2 May 2020 18:42:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <012e8bc3-df4b-3884-4e54-5fe7ef4248cb@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02.05.2020 09:28, Paul Eggert wrote: > On 5/1/20 6:07 PM, Dmitry Gutov wrote: > >> They very rarely use the phrase "constant objects", however. Instead, it's >> almost always "objects that appears as a constant [in code]", "object ... used >> as a quoted constant", "object may not ... appear as constants in code", >> "objects are similar as a constant". > > We could use similar circumlocutions. Or instead of saying "constant" we could > say "unchanging", as distinct from "unchangeable". (It beats > "object-that-should-not-be-changed" or "glass object - you changed it, you broke > it!". :-) The usual word for this notion is "constant", though. "glass objects" or "voldemort objects" all sound better to me. :-) "unchanging" is one of the meanings of "constant". It's a property of a process, not something we can call a value out of context. CLtL uses the term "coalesced", though. We can consider it. >> IOW, it's the difference between constant values and constant pointers to >> [mutable] values. > > I don't see that. A constant (or "unchanging") string is like a mutable string, > except you shouldn't change it. An unchanging string is just a string that nobody changed. "Please don't change unchanging strings" is a prohibition of time travel. > There's no sense in CLtL in which a mutable > object must be implemented via a pointer to a value whereas a constant must not > be implemented that way. The "objects that appear as a constant" are objects to which exist references from executable code, and where such references are "constant" (or possibly constant, since an implementation might opt not to coalesce the values). That why it's about constant references (and objects to which such references exist). >> there is no juxtaposition of "mutable objects" vs "constant objects" >> anywhere in there > > Yes, the mutable/immutable terminology revolution happened mostly after CLtL was > written. Not just because of that. >> So the section >> "Constants and Mutability", even though it has valuable information, could use a >> full rewrite. And could probably move to end of the "Self-Evaluating Forms" >> section. > > Whether an object is constant is distinct from whether it's derived from a > self-evaluating form, because one can have constants that were never derived > from any self-evaluating form. Examples? I mean, A mutable object can become constant if it is part of an expression that is evaluated does add some cases not covered by self-evaluating forms, but those are more complex cases (e.g. creating forms programmatically and then passing them to 'eval'), and then the programmer might justifiably be expected to use their head. The self-evaluating forms case is arguably less obvious. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2020 19:37: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 To: Dmitry Gutov , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15884481778335 (code B ref 40671); Sat, 02 May 2020 19:37:02 +0000 Received: (at 40671) by debbugs.gnu.org; 2 May 2020 19:36:17 +0000 Received: from localhost ([127.0.0.1]:53965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUxvt-0002AN-3y for submit@debbugs.gnu.org; Sat, 02 May 2020 15:36:17 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUxvd-00029Y-EI for 40671@debbugs.gnu.org; Sat, 02 May 2020 15:36:15 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DFB6916007E; Sat, 2 May 2020 12:35:55 -0700 (PDT) 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 qVMSYFm01hEi; Sat, 2 May 2020 12:35:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F0A821600DB; Sat, 2 May 2020 12:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 vCZxJKvfgSb2; Sat, 2 May 2020 12:35:54 -0700 (PDT) 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 9D08316007E; Sat, 2 May 2020 12:35:54 -0700 (PDT) References: <6d1015da-0dc1-376c-f84b-5e3ee3149213@cs.ucla.edu> <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <012e8bc3-df4b-3884-4e54-5fe7ef4248cb@cs.ucla.edu> <37a54ac2-da80-ca35-9c01-38c8e12a4b5f@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Sat, 2 May 2020 12:35:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <37a54ac2-da80-ca35-9c01-38c8e12a4b5f@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> There's no sense in CLtL in which a mutable >> object must be implemented via a pointer to a value whereas a constant= must not >> be implemented that way. >=20 > The "objects that appear as a constant" are objects to which exist refe= rences > from executable code, and where such references are "constant" (or poss= ibly > constant, since an implementation might opt not to coalesce the values)= . That > why it's about constant references (and objects to which such reference= s exist). I don't understand this point. It sounds like you might be trying to distinguish between constant refere= nces (i.e., pointers that don't change) and constant objects implemented via references (i.e., the pointed-to values don't change). However, whether t= he references themselves are constant is independent of the issue at hand. T= he issue wouldn't change, for example, if Emacs relocated objects so that references were updated regardless of whether the objects' values were co= nstant. >> Whether an object is constant is distinct from whether it's derived fr= om a >> self-evaluating form, because one can have constants that were never d= erived >> from any self-evaluating form. >=20 > Examples? One example is (aset (symbol-name 'car) 0 ?d), which I mentioned a while = ago. Here's a trickier one: (let ((constant-string (aref (symbol-function 'error) 1))) (aset constant-string 0 183) (number-sequence 0 1 0)) This also provokes undefined behavior at the C level while number-sequenc= e is doing its thing; my Emacs dumps core, yours may do something different. I= 'm sure there are other examples. The point is that programs should not modify co= nstants. It would be nice if Emacs reliably signaled these errors and we should be= able to do a better job of that than we're doing now. However, doing a better = job would require interpreter surgery that would be too much for emacs-27. > =C2=A0 A mutable object can become constant if it is part of an express= ion > =C2=A0 that is evaluated >=20 > does add some cases not covered by self-evaluating forms, but those are= more > complex cases (e.g. creating forms programmatically and then passing th= em to > 'eval'), and then the programmer might justifiably be expected to use t= heir > head. The self-evaluating forms case is arguably less obvious. The documentation should not limit itself to self-evaluating forms when discussing this problem area. Although it's OK for the doc to emphasize self-evaluating forms, they are not the whole story here. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 01:31: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15884694486875 (code B ref 40671); Sun, 03 May 2020 01:31:02 +0000 Received: (at 40671) by debbugs.gnu.org; 3 May 2020 01:30:48 +0000 Received: from localhost ([127.0.0.1]:54360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV3Sy-0001mR-Dg for submit@debbugs.gnu.org; Sat, 02 May 2020 21:30:48 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:46650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV3Sw-0001f4-6Q for 40671@debbugs.gnu.org; Sat, 02 May 2020 21:30:46 -0400 Received: by mail-wr1-f50.google.com with SMTP id f13so16583508wrm.13 for <40671@debbugs.gnu.org>; Sat, 02 May 2020 18:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=65FpDaTuluePD5YQBFh4uRLmSFbdqly2+itM1ppXMF8=; b=fFOh4VenJbj3h1hFFNuuwdo8/mbyN5p3TB8Y92D1oDu3XfwCrsE43kXK9M3jckK7md COrSoQjUjNZr2rhalQJuZSb9xiJ4p1fIukLH6BNsb5OoDmZ/vwY2+0qfcZ+iunD0dMTl D7Wb7qybUfmaoVxHN2rOvvS0tCZKi5yV7vOKdiuk7hJUdFXgWW85zJ+wXnBHMr+q8G7R ifBbfcSu6bEVL7Vi5LssBv9uRj7VTYDHB80C66mtgY09ZkCelNoUJ9RN+4ww3979OVKA zYcKuCRufYo2/CVR6J4iyJOTtFgc9nBh1Okjljg9c+BwMHc3ogctPDNHj6xNOp7NoBN0 D/tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=65FpDaTuluePD5YQBFh4uRLmSFbdqly2+itM1ppXMF8=; b=NzLhdextYQPt5aYedil9456Wk/9z06trJPkspB99jrHgT7GaGsAh2+ucXEF3E07BFp 3IjIdY0JqwTRLhCa5DTV8xv5FJYTM377W2w2QGstQ+3gv5MazktmpJwGGa9bhkY2JdbH CSYAEpVPo1lPOR2tupHxp+4UCqhKkuLfoS5U4vn8dHCaqhrlKKXwmIvpV/5LjfzYOhlI Ys4iJh2+TsvYFbuftBmrn2la4ZAehHVW+wvzfVC+s29ghys3AxZDN6VXLFYjPIv/aHI3 MI0VSmw40EGppmc1b6OC8eiYtj1pq7WoRn/Ihek7SY4veTDLv0gmiuIV6DagnWbhRi9J RSZw== X-Gm-Message-State: AGi0PuZrFjfH53F25o3T5hMzu9si5Gj4cNaaRDGOt45mx7lJzlSl6hQm mTZjBlNZfYjmlfFN2o2RCv8= X-Google-Smtp-Source: APiQypK0BFGCWnRm6tNgdwk6xOyKW3kUothXXAjpiJpFOylfV6U0krJoEUTJ0RqcSziM1zHxpOG5dw== X-Received: by 2002:adf:f8c6:: with SMTP id f6mr12874775wrq.276.1588469440257; Sat, 02 May 2020 18:30:40 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a205sm7085036wmh.29.2020.05.02.18.30.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 May 2020 18:30:39 -0700 (PDT) References: <286139d2-bbe1-2d5a-bec1-f781666376f1@yandex.ru> <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <012e8bc3-df4b-3884-4e54-5fe7ef4248cb@cs.ucla.edu> <37a54ac2-da80-ca35-9c01-38c8e12a4b5f@yandex.ru> From: Dmitry Gutov Message-ID: <9375aaeb-2a9a-b307-c793-0d99328201ea@yandex.ru> Date: Sun, 3 May 2020 04:30:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02.05.2020 22:35, Paul Eggert wrote: >> The "objects that appear as a constant" are objects to which exist references >> from executable code, and where such references are "constant" (or possibly >> constant, since an implementation might opt not to coalesce the values). That >> why it's about constant references (and objects to which such references exist). > > I don't understand this point. > > It sounds like you might be trying to distinguish between constant references > (i.e., pointers that don't change) and constant objects implemented via > references (i.e., the pointed-to values don't change). I'm making a semantic point: these values are special because they are at the other end of a certain set of "constant references". Not because they have any other property themselves, like being immutable. > However, whether the > references themselves are constant is independent of the issue at hand. The > issue wouldn't change, for example, if Emacs relocated objects so that > references were updated regardless of whether the objects' values were constant. Object relocation is immaterial for the semantics of Elisp. Even if the objects were relocated from time to time, the references would be updated, and would point to the same objects again, and thus be constant. >>> Whether an object is constant is distinct from whether it's derived from a >>> self-evaluating form, because one can have constants that were never derived >>> from any self-evaluating form. >> >> Examples? > > One example is (aset (symbol-name 'car) 0 ?d), which I mentioned a while ago. > Here's a trickier one: > > (let ((constant-string (aref (symbol-function 'error) 1))) > (aset constant-string 0 183) > (number-sequence 0 1 0)) > > This also provokes undefined behavior at the C level while number-sequence is > doing its thing; my Emacs dumps core, yours may do something different. I'm sure > there are other examples. The point is that programs should not modify constants. These two are pretty obviously "undefined behavior", and anybody who does that have only themselves to blame. So of course it's good to document this, but since apparently you're not going to fix the semantic problem currently under discussion yourself, I'm not sure I can keep this info. You're welcome to re-add it, of course. > It would be nice if Emacs reliably signaled these errors and we should be able > to do a better job of that than we're doing now. However, doing a better job > would require interpreter surgery that would be too much for emacs-27. Of course. >>   A mutable object can become constant if it is part of an expression >>   that is evaluated >> >> does add some cases not covered by self-evaluating forms, but those are more >> complex cases (e.g. creating forms programmatically and then passing them to >> 'eval'), and then the programmer might justifiably be expected to use their >> head. The self-evaluating forms case is arguably less obvious. > > The documentation should not limit itself to self-evaluating forms when > discussing this problem area. Although it's OK for the doc to emphasize > self-evaluating forms, they are not the whole story here. The "whole story" can be enumerated in some place, sure. Self-evaluating forms seem to be the most important area to cover, though. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 07:41: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 To: Dmitry Gutov , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158849165415036 (code B ref 40671); Sun, 03 May 2020 07:41:02 +0000 Received: (at 40671) by debbugs.gnu.org; 3 May 2020 07:40:54 +0000 Received: from localhost ([127.0.0.1]:54587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV9F7-0003uS-Tq for submit@debbugs.gnu.org; Sun, 03 May 2020 03:40:54 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV9F6-0003uD-4A for 40671@debbugs.gnu.org; Sun, 03 May 2020 03:40:52 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D6172160066; Sun, 3 May 2020 00:40:45 -0700 (PDT) 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 EYd9zO6UEDAQ; Sun, 3 May 2020 00:40:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1905D160097; Sun, 3 May 2020 00:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 whLLkaHieulc; Sun, 3 May 2020 00:40:44 -0700 (PDT) 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 CC50F160066; Sun, 3 May 2020 00:40:44 -0700 (PDT) References: <10b89e6f-6fa6-f855-65b6-3361a74472d3@cs.ucla.edu> <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <012e8bc3-df4b-3884-4e54-5fe7ef4248cb@cs.ucla.edu> <37a54ac2-da80-ca35-9c01-38c8e12a4b5f@yandex.ru> <9375aaeb-2a9a-b307-c793-0d99328201ea@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <7fe0574a-62ae-94fb-2e55-1a69de6ce828@cs.ucla.edu> Date: Sun, 3 May 2020 00:40:44 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <9375aaeb-2a9a-b307-c793-0d99328201ea@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/2/20 6:30 PM, Dmitry Gutov wrote: > I'm making a semantic point: these values are special because they are at the > other end of a certain set of "constant references". Not because they have any > other property themselves, like being immutable. I don't see why this semantic point makes a difference to the user. Regardless of whether the objects are targets of "constant references" (whatever that means), programs should not modify the objects in question. And if the semantic point makes no practical difference, why complicate the manual with it? It's simpler just to say: programs shouldn't modify these objects. > The "whole story" can be enumerated in some place, sure. Self-evaluating forms > seem to be the most important area to cover, though. They're not the only thing to cover, and attempting to shoehorn this all into self-evaluating forms could even be misleading. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 16:45: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15885242745825 (code B ref 40671); Sun, 03 May 2020 16:45:01 +0000 Received: (at 40671) by debbugs.gnu.org; 3 May 2020 16:44:34 +0000 Received: from localhost ([127.0.0.1]:57773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVHjG-0001Vt-J9 for submit@debbugs.gnu.org; Sun, 03 May 2020 12:44:34 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:44918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVHjB-0001VZ-KW for 40671@debbugs.gnu.org; Sun, 03 May 2020 12:44:33 -0400 Received: by mail-wr1-f46.google.com with SMTP id d17so17990437wrg.11 for <40671@debbugs.gnu.org>; Sun, 03 May 2020 09:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rC0fyHmcLAmzkjEPqp9afvKxbu1ijnwBS0d/bDLlbFc=; b=IaKEwnAh92HVmdCtmcHhsYk9QOSCBMupL/ssJFG3XVsmCZhLt/rwF2Qw9YDlbUhvrM uDumAPJpLDG0HukdJvkRleaUyPIcKNI4nUstIQYQ4wDVkNueWDovG3IpsCG49enfdSqA XbSiAqh6I+o5/5fYY3V7ogtpUk/0aOXN+UeRKZ8pXqy3R5zSZIM4KlBiMkL/Xd4Ysu9Q i+E7xGmZMWUUuR1lbeFMVaFBxLvS0+cSd+LMXGfj5Z/V8y/MXpREz2lva6jpwMOAqUXM cIbPv5BLSlyBFXf9xDLy1cloUEujoKZRasbXjiaPUW1LJYuyyHAqfCexYbeEg7B9Szck QYNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rC0fyHmcLAmzkjEPqp9afvKxbu1ijnwBS0d/bDLlbFc=; b=Sw/SpIwfISR5/fUFzdPCHgi7tQuREWGtM9mNLapJtBlMKuYNnR6ZPNQmeCXSiXYcct dx+m6t+aYYjWONeI6G7CBbfZs4eSXrCwEABFsv4OrpAt/BP/K+tbr/utCg973r5Q36/m PAaiTE/AIC7O5L4vVG8gR68jHg51deobAeihJphR06LQ366pJfJU1yX9ivy74l2Cx9t2 rchUogrPzu4pOuSh4sx9oNgRu7m19Y4JW6sbR759PtuVyJFGIT4H4vAsKJk7YkZQ82A6 wPR3QIiUk5nZfHNHVLw7r9U1d0KebZ04q67cYlJXKXH0D56OBuNU/paNfo7032Esnotl s3Xw== X-Gm-Message-State: AGi0PuZat1t6WzNq0kfDHaI4uF2Z8KYAKrhRDhF8stirGzuXo69CB5// L42+o3psSgugCErkTWpXF+I= X-Google-Smtp-Source: APiQypK2acoGT08P/N6m+jom88PNV/JQ3Rx5bl3CZIVvIm5nYp2M4ysdnSdOA3TXNqMbCGXacPEa2Q== X-Received: by 2002:a5d:510f:: with SMTP id s15mr834812wrt.103.1588524263772; Sun, 03 May 2020 09:44:23 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id e13sm13361096wrw.88.2020.05.03.09.44.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 May 2020 09:44:23 -0700 (PDT) References: <8542efe2-c4a6-1da5-2513-7ffcaa6c4ec9@yandex.ru> <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Dmitry Gutov Message-ID: <91857438-f44a-90f4-dfe2-a32224ba3994@yandex.ru> Date: Sun, 3 May 2020 19:44:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <7fe0574a-62ae-94fb-2e55-1a69de6ce828@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 03.05.2020 10:40, Paul Eggert wrote: > It's simpler just to say: programs shouldn't modify these objects. Which objects, then? > They're not the only thing to cover, and attempting to shoehorn this all into > self-evaluating forms could even be misleading. Which section would that go into? "Constants and Mutability" doesn't work. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 20:49: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 To: Dmitry Gutov , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15885389035239 (code B ref 40671); Sun, 03 May 2020 20:49:02 +0000 Received: (at 40671) by debbugs.gnu.org; 3 May 2020 20:48:23 +0000 Received: from localhost ([127.0.0.1]:58146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVLXD-0001MR-3Q for submit@debbugs.gnu.org; Sun, 03 May 2020 16:48:23 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50096) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVLXB-0001MB-CF for 40671@debbugs.gnu.org; Sun, 03 May 2020 16:48:21 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CE97B160066; Sun, 3 May 2020 13:48:15 -0700 (PDT) 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 G1eu55IVVbYQ; Sun, 3 May 2020 13:48:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2178C160097; Sun, 3 May 2020 13:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 z6S1qdT9OJGc; Sun, 3 May 2020 13:48:15 -0700 (PDT) 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 D4104160066; Sun, 3 May 2020 13:48:14 -0700 (PDT) References: <293d0eab-4617-08fe-aafa-d6841a750af0@cs.ucla.edu> <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <880dc34b-46a9-0149-3c6e-0a951a70125d@cs.ucla.edu> Date: Sun, 3 May 2020 13:48:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <91857438-f44a-90f4-dfe2-a32224ba3994@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/3/20 9:44 AM, Dmitry Gutov wrote: > On 03.05.2020 10:40, Paul Eggert wrote: >> It's simpler just to say: programs shouldn't modify these objects. > > Which objects, then? Objects that the documentation currently calls "constants". (If there's a better term than "constants" we haven't found it yet.) >> They're not the only thing to cover, and attempting to shoehorn this all into >> self-evaluating forms could even be misleading. > > Which section would that go into? "Constants and Mutability" doesn't work. If we change the word "constants" to something else, we would presumably retitle the section and adjust its contents accordingly. Regardless of which word is chosen we should document the issue, which is broader than that of constants from self-evaluating forms. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 22:18: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158854427113881 (code B ref 40671); Sun, 03 May 2020 22:18:01 +0000 Received: (at 40671) by debbugs.gnu.org; 3 May 2020 22:17:51 +0000 Received: from localhost ([127.0.0.1]:58303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVMvn-0003bp-5G for submit@debbugs.gnu.org; Sun, 03 May 2020 18:17:51 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:46368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVMvl-0003bc-TJ for 40671@debbugs.gnu.org; Sun, 03 May 2020 18:17:50 -0400 Received: by mail-wr1-f41.google.com with SMTP id f13so18643581wrm.13 for <40671@debbugs.gnu.org>; Sun, 03 May 2020 15:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6Sf2+uvXgdHkZmrnxQmk303+RSe1TX0w2VugVUlJn3U=; b=CWI4yHQ9yaBNE8IDvjf70LfHndqW5MM3QE7ojtf/A1Ub4kGcLhegTf7t5gG9JS2yfU a9Fc1V4C8beqVj4nRoR5pFcyppmRvEHFrUVkfJ6GGJROilQmEK+Y5csYkwvm0a838vzt OwUWzjLVK/Ndqw90CkuFnom93u2DCRxYQv0woB4SIxcPfK8ldrvSqZo+iiXwPrxXGHqC Q+LMYK4lKPxmjbBtfd1dl87hlAl9DaNxBzY2PMciOCV0uZesZpOoJffVrmep5vtCSs22 Ozrikyo4L+v6jfnBCayTIGlloXWoCDKKua6J3DvYCpm9uwicggaIO+49KOdwz9aOlIoi KR8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6Sf2+uvXgdHkZmrnxQmk303+RSe1TX0w2VugVUlJn3U=; b=uGFMx5CiLxJfi0uoR+m0URkc6e/i8poIFOGo4cdqAGhvtjlhlk9bOp4hVIytYlAUdB DHfrAZVAn05/Iu3GtwXPeG2HUTTS1S5joXAy7e8n/NwDgZXvQQRjqA9f6s6bUVryAoGa Y7l3UP0b/P0KdbfmODQ0Ln/XsvEg+T71h9UX6PlMR3t62a4ZelQJBdX1o4KyIs0a1pDX AS7UZK3LqAiAeZ0pFyaQRttEm1PPqPkGhWOhVETAWcUh76kyzsQiTs9ilmBn76mwVTVm LYfJAnHtNMh7yuPl7K9ScmA9DPRyIlZU7TO81MBpxIcfIUC4c9P1ngIt/KOJgkzCXzUr ziWA== X-Gm-Message-State: AGi0PubwrIqZvDZ+4BWepTlKaOjVPnpZZcJpeGiwlh+e1aC1TgwE4tWJ KVPDun7hcrsSK3N7E8kmLd8= X-Google-Smtp-Source: APiQypKbyHRKJjKf9aydwJmRtrMr4tdKrsuy7LFEHNHQY1yeDHM+09bV36c+T5vb/em7OwZAu6uQtQ== X-Received: by 2002:a5d:42c8:: with SMTP id t8mr15462625wrr.70.1588544264074; Sun, 03 May 2020 15:17:44 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id y31sm8605161wrd.83.2020.05.03.15.17.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 May 2020 15:17:43 -0700 (PDT) References: <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Dmitry Gutov Message-ID: <7f60a04c-4422-19ab-fc7a-3180e49c8474@yandex.ru> Date: Mon, 4 May 2020 01:17:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <880dc34b-46a9-0149-3c6e-0a951a70125d@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 03.05.2020 23:48, Paul Eggert wrote: > If we change the word "constants" to something else, we would presumably retitle > the section and adjust its contents accordingly. Regardless of which word is > chosen we should document the issue, which is broader than that of constants > from self-evaluating forms. Yes. But you supposedly want to move some of the contents (which don't pertain exactly to self-evaluating forms) to some other section. Could you make that naming choice yourself? I can only move it to one of the existing ones. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 22:19: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158854431013977 (code B ref 40671); Sun, 03 May 2020 22:19:01 +0000 Received: (at 40671) by debbugs.gnu.org; 3 May 2020 22:18:30 +0000 Received: from localhost ([127.0.0.1]:58312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVMwP-0003dN-LV for submit@debbugs.gnu.org; Sun, 03 May 2020 18:18:29 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:51919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVMwO-0003dA-F7 for 40671@debbugs.gnu.org; Sun, 03 May 2020 18:18:28 -0400 Received: by mail-wm1-f45.google.com with SMTP id x4so6263913wmj.1 for <40671@debbugs.gnu.org>; Sun, 03 May 2020 15:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=n1uTEwApBnr2qI4nqSbA3Q90LMQSWDm8bLTDB3ajjRg=; b=hTlytintAMa+gd6mxBZVg/ZBAf/7GjiTTiBdIAwYPa6dvVKIEemF53H4g/AEFvElgj OS4hnAqzAG07mekBOpFiP7NpatDZen6MmgiomMwdujDhIJG58apKd/df+GXOms+d6NfV 7F/C1snEHu1VixoTdIzH/V03gmmtXYzKDe7OKdQVx/em1yWoPeT7NK/zaJtotat4al+Z Z1ZzOcjW9lyPjFw+knOJH71+RnTIbFWFTInj7LDyKWvOlaQIPLCsPdw6LEZ3LEs5GlDu zrEzt01PvoFPufiXYSsGSCkj997/c1nU19o8jdBXhea1qlMveXscwpjv1eRmLdIHE0vE ac9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n1uTEwApBnr2qI4nqSbA3Q90LMQSWDm8bLTDB3ajjRg=; b=pCG3I9CzX2LtruR7IiEkxAp2a+JuxZC3319PogPYA6vuVYQvFhNT0nyFyXlrvBjlYA h93cIDAqoKyJgnRTL941XQqqkbVyq5iuiFoJVfaAESIeIR4aq7oSTki34CXSnaD2+op1 fBOftjWqva4bcKHRsOlAwNL0kZYPC3Bm4GNGsqA/ii2v/cTEDcemlaZyG+dLJkwuHUBv dEgyU/E/M+TaVES62PhLoN4uAnYaC8q2euvGoZBLSv3CCjzKeKaIcr2niNLe3VsRI4H8 tA4N9UpnwPHJCUvxlq3Wl+Bqg17kYOySsSGqmBlwddNLBJ8kyKtSnX45ZpU9f0iW952K zXWw== X-Gm-Message-State: AGi0Pua57XyNFMRDz8VPeg1+VGXhJFZ+s50uTeUz3/xoRH2f/9dQDTO7 U+PsgX8TgwyZYKUCnTOaf3E= X-Google-Smtp-Source: APiQypIzBqVBa8fTK6QODAFGpEuJNo94rmpf3JzZc41GaPn6OkHQadUVzYFNlaTH2URV6FhnuCWrJw== X-Received: by 2002:a1c:dc0a:: with SMTP id t10mr10909170wmg.113.1588544302435; Sun, 03 May 2020 15:18:22 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id y10sm10248490wma.5.2020.05.03.15.18.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 May 2020 15:18:21 -0700 (PDT) References: <4085994e-f42d-b90f-9c86-ad42689bbff2@yandex.ru> <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Dmitry Gutov Message-ID: <9c46b93e-a855-0be0-7ab0-50cb8c5cd74d@yandex.ru> Date: Mon, 4 May 2020 01:18:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <880dc34b-46a9-0149-3c6e-0a951a70125d@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 03.05.2020 23:48, Paul Eggert wrote: > (If there's a better > term than "constants" we haven't found it yet.) "Objects referenced from executable code", presumably. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 22:41: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 To: Dmitry Gutov , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158854560516277 (code B ref 40671); Sun, 03 May 2020 22:41:02 +0000 Received: (at 40671) by debbugs.gnu.org; 3 May 2020 22:40:05 +0000 Received: from localhost ([127.0.0.1]:58365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVNHI-0004ET-U5 for submit@debbugs.gnu.org; Sun, 03 May 2020 18:40:05 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVNHH-0004DX-86 for 40671@debbugs.gnu.org; Sun, 03 May 2020 18:40:03 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4BFB5160052; Sun, 3 May 2020 15:39:57 -0700 (PDT) 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 91sz2JSM4IL3; Sun, 3 May 2020 15:39:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7D5E6160066; Sun, 3 May 2020 15:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 Jf04jm4moW22; Sun, 3 May 2020 15:39:56 -0700 (PDT) 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 A9089160052; Sun, 3 May 2020 15:39:55 -0700 (PDT) References: <9cfc3b63-7df6-145a-8a78-e3320b6d3861@cs.ucla.edu> <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Sun, 3 May 2020 15:39:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <9c46b93e-a855-0be0-7ab0-50cb8c5cd74d@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/3/20 3:18 PM, Dmitry Gutov wrote: > On 03.05.2020 23:48, Paul Eggert wrote: >> (If there's a better >> term than "constants" we haven't found it yet.) > > "Objects referenced from executable code", presumably. A fair number of objects fit that category. (The objects that don't are typically garbage collected. :-) So that term doesn't describe what we want clearly and accurately; plus, it's pretty long.... > On 03.05.2020 23:48, Paul Eggert wrote: >> If we change the word "constants" to something else, we would presumably retitle >> the section and adjust its contents accordingly. Regardless of which word is >> chosen we should document the issue, which is broader than that of constants >> from self-evaluating forms. > > Yes. But you supposedly want to move some of the contents (which don't pertain exactly to self-evaluating forms) to some other section. There must be some miscommunication, as I thought you wanted to move some of that section's contents. I vaguely recall responding that something along those lines could work, but I don't recall any specific suggestion after that. > Could you make that naming choice yourself? I can only move it to one of the existing ones. I don't understand this request; I don't know what you mean by "it" or by "moving" or by "existing ones". If you're talking about the title of the "Constants and Mutability" section, the current term "constants" is fine with me, as it follows existing practice in CLtL etc. I'm open for suggestions for changing the term, but we haven't come up with a better term as far as I can see, or even a term that's roughly equal in quality. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 22:54: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158854640917510 (code B ref 40671); Sun, 03 May 2020 22:54:01 +0000 Received: (at 40671) by debbugs.gnu.org; 3 May 2020 22:53:29 +0000 Received: from localhost ([127.0.0.1]:58383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVNUH-0004YL-3t for submit@debbugs.gnu.org; Sun, 03 May 2020 18:53:29 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:45166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVNUF-0004Y9-VH for 40671@debbugs.gnu.org; Sun, 03 May 2020 18:53:28 -0400 Received: by mail-wr1-f52.google.com with SMTP id o27so13423261wra.12 for <40671@debbugs.gnu.org>; Sun, 03 May 2020 15:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dbAqAVwRdnm4ZmtueUe8WRcmZB/G0VswM+FEBBJoSUk=; b=boeqycdBPrzkWzyaNeW8OTwmxpnRP4MSL5zlzmudgioupYqZIPzc+FrTMA/Jt0ZY9k 1J7dfPW1Vr3LLmVmxFWBKJ4yo7+csazI6jMSIGbgyXPfer6xwUROKIEROZgq7R4hP2/v OlQX6mRa/oysuPkWuXqtiKvCSA0x1ADHVjeP6iirIIEJg+HmWxcUOe7Opublf6na1Rkb GCpQLUx0v/CGi4MrG0m3VDFSNI7AplEhAMwbu+hqfqM/Es2L7d9hBOPifTJotWObrVxP 9klJCHDjZzdrmYvxrmjCsD5vGHYC5Pz1cc0xaDitbrCsA8ab1P4UASDxDRfSaiw8rpzf uzxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dbAqAVwRdnm4ZmtueUe8WRcmZB/G0VswM+FEBBJoSUk=; b=FiQbqI5zLrx9VUCUR9WXmmmOc88c70cGVuOClUutZTccsSrs+qi2KFmdg2QezfGWJ1 5Bydiar1BZbX+tzys1qs8PyESB6y/cylx3rRaQKPSBX5LTKRmy4w66Gzq7wm0sIqWw5/ 55Ih3f12WjaDp7z3EqdK7roUBTmAFVgPtu0KeTvZI5Exmno3cSn9Q9Ul8BhJ5EPIkjyx NG6Wc+4tNBKBPCv4wwicGPvWiC/C2f5I8kWqkHc4YFWipQuCLeOuDrM8ETa+JpQ1XgnJ 9xYsfotZD1rZoKx0yhBUtFHMnVWklyjSY0KFHPXzepE4HYRoEW/lLVXyZVNfF4D9UFL6 INbg== X-Gm-Message-State: AGi0PubJq9EMa5iLFWdVPsNpM2DMZHyfy7upH00RotoVmGmDWFMyU8T9 CuM4nBQJm0IOFcmbE2/Uxdg= X-Google-Smtp-Source: APiQypLZ0ldkzYggpitIaVUTbFbX6Uw3nCk3jLQYY2y8DWKnMTaTU+amZb9ya9IQa0kJJ3/3Hp9RXg== X-Received: by 2002:a5d:4d0b:: with SMTP id z11mr5211667wrt.81.1588546402050; Sun, 03 May 2020 15:53:22 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id u7sm12053468wmg.41.2020.05.03.15.53.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 May 2020 15:53:21 -0700 (PDT) References: <72399223-0ab5-dbe4-5027-d929450a4df0@yandex.ru> <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Dmitry Gutov Message-ID: <48e90f87-1519-9101-d54b-4bfd81a0c936@yandex.ru> Date: Mon, 4 May 2020 01:53:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 04.05.2020 01:39, Paul Eggert wrote: > A fair number of objects fit that category. (The objects that don't > are typically garbage collected. So that term doesn't describe what > we want clearly and accurately; plus, it's pretty long.... Example, please. > If you're talking about the title of the "Constants and Mutability" section, the > current term "constants" is fine with me, as it follows existing practice in > CLtL etc. I'm open for suggestions for changing the term, but we haven't come up > with a better term as far as I can see, or even a term that's roughly equal in > quality. I'm clearly not the only one objecting to the new terms. And especially the juxtaposition of "constants and mutability" that you added to the docs. It would be a shame to revert your whole work, though. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 23:11: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 To: Dmitry Gutov , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158854745827171 (code B ref 40671); Sun, 03 May 2020 23:11:01 +0000 Received: (at 40671) by debbugs.gnu.org; 3 May 2020 23:10:58 +0000 Received: from localhost ([127.0.0.1]:58427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVNlC-00074A-It for submit@debbugs.gnu.org; Sun, 03 May 2020 19:10:58 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVNlA-00073x-K3 for 40671@debbugs.gnu.org; Sun, 03 May 2020 19:10:57 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 29F3D160066; Sun, 3 May 2020 16:10:51 -0700 (PDT) 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 h8514Mv9TsGW; Sun, 3 May 2020 16:10:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6AED8160052; Sun, 3 May 2020 16:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 Jb8QBV73LyxR; Sun, 3 May 2020 16:10:50 -0700 (PDT) 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 073EA160066; Sun, 3 May 2020 16:10:50 -0700 (PDT) References: <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <252d6368-ddea-2f41-b53f-cd927ebc3d1d@cs.ucla.edu> Date: Sun, 3 May 2020 16:10:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <48e90f87-1519-9101-d54b-4bfd81a0c936@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/3/20 3:53 PM, Dmitry Gutov wrote: > On 04.05.2020 01:39, Paul Eggert wrote: >> A fair number of objects fit that category. (The objects that don't >> are typically garbage collected.=C2=A0 So that term doesn't describe w= hat >> we want clearly and accurately; plus, it's pretty long.... >=20 > Example, please. The term you used was "Objects referenced from executable code". But that= term includes pretty much every object used in Elisp, at least until the objec= t becomes unreachable and is garbage-collected. The concept you were describing is not that general: it's limited to obje= cts that are part of an expressions that are evaluated. So a better term woul= d be something like "Objects that are part of expressions that are evaluated" = - but this term is way too long; plus it doesn't accurately describe all the problematic objects, as there are other reasons that some objects should = not be modified. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 May 2020 10:17: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158858738318176 (code B ref 40671); Mon, 04 May 2020 10:17:02 +0000 Received: (at 40671) by debbugs.gnu.org; 4 May 2020 10:16:23 +0000 Received: from localhost ([127.0.0.1]:59023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVY99-0004j6-Mm for submit@debbugs.gnu.org; Mon, 04 May 2020 06:16:23 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:38396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVY98-0004ir-AF for 40671@debbugs.gnu.org; Mon, 04 May 2020 06:16:22 -0400 Received: by mail-wm1-f41.google.com with SMTP id g12so8355098wmh.3 for <40671@debbugs.gnu.org>; Mon, 04 May 2020 03:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=szhdnihzZo2rHItURi4koS+DzAmO/6AUfYgKso+AePw=; b=fZpGau02xuRYsN+w3MMqHKakUVtdXgaGCfz5gC8xgZYoy5TBXNGCwzdXH32c3568ZF TVYcA5dmidPPVyw5rIE2ygzUUHuRSszfWv5Pojs/3DmyVKt0dzjrwU9JdBx+19+pYlFq bQ1wO72xh+QoUmRUjmV28yX3aQLVsml7UqBsKCz1hbA66kD8T2RT+0Vb9QLVQ4iNAAtS SAdnSjMgQtYMin5MDDYIk57mV7eDNwtN7pYvghxFpEykgtA2j5A5BRlNvDnlISsrSARE V6tSuuO7aO9LzQ5BAtBJpJ7bwCsdVU08vsCII5E0iRiwuAznECQbWNlIy0k5NeIWvPxB XoBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=szhdnihzZo2rHItURi4koS+DzAmO/6AUfYgKso+AePw=; b=XGwEBBlaMiI9BJojoMRb85cV5Qpf9rBnYxCUhnE3kEcNRTMolvxE1pbaLRQqpBgbB1 6lXecw4pHZ81/HiBvmPAhr/uyWDygkFl2Jbxgg44/yBUbQ5Oe5EMiVmRr60dWX6HUvBq RmY8osH1MJHraD/3NmiaFMeZBBclV5jTKDw8NF61Ry1Tq6KtYlogyzPUMS+aZKdGZcZp VJ46Yf7qsRi2/020qz18/6851enrWKYTUd4rmd1KNIZT4HfgNSXx0i7HzZqyDCsL4NXh ZAywyDaA1oc5THkPvRxOSpyvJaYk6mdR6r2881TNmRT24kWMlmGNBhWCBgE0oTF3ptQ0 8ezQ== X-Gm-Message-State: AGi0PuaOaSTOTViyzuUdUl2BcHLIkciX3vxfJ1Uj8XckrJht+YuT41JF vdpj3w1ozjqPH6nWeUnIqAc= X-Google-Smtp-Source: APiQypLTV1hZDlLCvJqV9VLqHahj7T/wjmCe+fTO0TopxJ3+6YNWRAOKRu+Gp8lj/7YkfrA5dLFTAw== X-Received: by 2002:a1c:68d7:: with SMTP id d206mr12953486wmc.29.1588587376500; Mon, 04 May 2020 03:16:16 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id w11sm12149583wmi.32.2020.05.04.03.16.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 May 2020 03:16:15 -0700 (PDT) References: <1a2d0454-baa4-9831-0e2c-4411eda1c2fe@yandex.ru> <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Dmitry Gutov Message-ID: <43d93102-d361-f64b-971b-909418b89fca@yandex.ru> Date: Mon, 4 May 2020 13:16:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <252d6368-ddea-2f41-b53f-cd927ebc3d1d@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 04.05.2020 02:10, Paul Eggert wrote: > The term you used was "Objects referenced from executable code". But that term > includes pretty much every object used in Elisp, at least until the object > becomes unreachable and is garbage-collected. I see. Could you present a specific counter-example, however? One where the phrasing "referenced from executable code" would apply, but "part of expressions that are evaluated" wouldn't. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 May 2020 17:53: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 To: Dmitry Gutov , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15886147509254 (code B ref 40671); Mon, 04 May 2020 17:53:01 +0000 Received: (at 40671) by debbugs.gnu.org; 4 May 2020 17:52:30 +0000 Received: from localhost ([127.0.0.1]:33916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVfGU-0002P9-OR for submit@debbugs.gnu.org; Mon, 04 May 2020 13:52:30 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50140) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVfGT-0002Ow-Dt for 40671@debbugs.gnu.org; Mon, 04 May 2020 13:52:25 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D66D3160079; Mon, 4 May 2020 10:52:19 -0700 (PDT) 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 6WJJYY9ojmop; Mon, 4 May 2020 10:52:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1B6151600CD; Mon, 4 May 2020 10:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 1OELQpNikvnk; Mon, 4 May 2020 10:52:19 -0700 (PDT) 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 B21FB160079; Mon, 4 May 2020 10:52:18 -0700 (PDT) References: <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <2ca64f28-1255-4135-6e45-0f0e12b9e72d@cs.ucla.edu> Date: Mon, 4 May 2020 10:52:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <43d93102-d361-f64b-971b-909418b89fca@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/4/20 3:16 AM, Dmitry Gutov wrote: > On 04.05.2020 02:10, Paul Eggert wrote: >> The term you used was "Objects referenced from executable code". But that term >> includes pretty much every object used in Elisp, at least until the object >> becomes unreachable and is garbage-collected. > > I see. Could you present a specific counter-example, however? > > One where the phrasing "referenced from executable code" would apply, but "part > of expressions that are evaluated" wouldn't. Pretty much any ordinary cons will do. In (let ((x (cons 0 0))) (setcar x 1)), for example, the cons is referenced from executable code but it's OK to modify the cons. The cons becomes unreachable when the 'let' finishes. The cons is not part of any expression that is evaluated. The problem here evidently is one of terminology, not of understanding the underlying issues. When I read "Objects referenced from executable code" I evidently got a different meaning than what you intended. These things happen when introducing a new terminology. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 May 2020 01:40: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15886427927038 (code B ref 40671); Tue, 05 May 2020 01:40:02 +0000 Received: (at 40671) by debbugs.gnu.org; 5 May 2020 01:39:52 +0000 Received: from localhost ([127.0.0.1]:34356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVmYp-0001pO-G5 for submit@debbugs.gnu.org; Mon, 04 May 2020 21:39:52 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:34418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVmYm-0001ou-PY for 40671@debbugs.gnu.org; Mon, 04 May 2020 21:39:49 -0400 Received: by mail-wm1-f48.google.com with SMTP id v4so1299609wme.1 for <40671@debbugs.gnu.org>; Mon, 04 May 2020 18:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=MYy8dBwBe1nRciaen1JIARd+ZRNUjxrsqQ++Qc+jkec=; b=WioyDqz44cfzV1Hxevaac99koogeBirENVlqJw94ADV1E67eMQhBZbJAweN1GpPfKb TWKEb5oi2Ah7RskxBcH2AkZBcbOL+OZlhUlQfmegbw5/hUsVcvZWlRUk9qApxRCzf4nk hIbhcquOwUAHESWplh2qpgLVTFkO6Ko/Ny8hGq01P4rMBsCisgQp5HSZTl2qPlu2Jp6i DyrdmTJEUF6wgxi4OyUD53VLBv3Xp3OOm3tZAb3qcarRUv12NwXc/JHzyQIczwF9kpej 5wW+T3wi7qXjPVdyq6EE/lXqb4f8ZmH/Ou+wDBHsAMoIwPB7Trj0sZdqnhJfCqkZ/IOg cYXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=MYy8dBwBe1nRciaen1JIARd+ZRNUjxrsqQ++Qc+jkec=; b=GEm6R9b+EE3rPz+T1bNFEbF6FKHJjRPwKUhnwQlEOSiv6iyePLBqYrFYPD3UBDKPTb jMwyUEnjc38vNhEFVc9p2eh+u6uc5UjSRXvUVv0F83cvpRHaq3mc+voct4Vwp8VTy3GV 33FM9q9ZNaQOJbhDZlRERB3+k5e9bcxEuOQ3Wds1n6uYEHmxxh6EvAOi1P25X5HdLrcE hdbRvkMTAwYfjUUGh4+GKd5EXkSWwNhiV3w5Fde3mEI0pvn71DtLHYK24r84o1zZIITO VrUoteFgx4CgBfJ63hpSqsRhQov23gDvWICnC/b5GbmbUxRJ4qoih1BNSGw0qNTyMMb6 SWtw== X-Gm-Message-State: AGi0PuZl9jg0ffChFSqbigy8WTS0/E2gJUu4EqvExZ4z5ZOCZLpxLlZw B1qByWCbcP+Wzt10vo1sBt0= X-Google-Smtp-Source: APiQypIniCrYRxKS5ENHeFMKSsSe6VUDQB6KCdFvhf3vcRH0K32FJspeo//oSWEKC6KD+4fiQ/URag== X-Received: by 2002:a1c:bd8b:: with SMTP id n133mr408369wmf.175.1588642782809; Mon, 04 May 2020 18:39:42 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id h137sm3552839wme.0.2020.05.04.18.39.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 May 2020 18:39:41 -0700 (PDT) References: <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Dmitry Gutov Message-ID: Date: Tue, 5 May 2020 04:39:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <2ca64f28-1255-4135-6e45-0f0e12b9e72d@cs.ucla.edu> Content-Type: multipart/mixed; boundary="------------AB214B005BE8D93534916131" Content-Language: en-US X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) This is a multi-part message in MIME format. --------------AB214B005BE8D93534916131 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 04.05.2020 20:52, Paul Eggert wrote: > Pretty much any ordinary cons will do. In (let ((x (cons 0 0))) (setcar x 1)), > for example, the cons is referenced from executable code but it's OK to modify > the cons. The cons becomes unreachable when the 'let' finishes. The cons is not > part of any expression that is evaluated. But, I mean, if we just make it a literal: (let ((x '(0 . 0))) (setcar x 1)) ...it also becomes okay to modify it because the cons becomes unreachable right away. Even so, we strongly recommend against this in the manual now. When the form above is a part of a function body, however, then it's *really* inadvisable to use the latter option. > The problem here evidently is one of terminology, not of understanding the > underlying issues. When I read "Objects referenced from executable code" I > evidently got a different meaning than what you intended. These things happen > when introducing a new terminology. I have asked for clarification to try to come up with better phrasing. But to be frank it's not so important to me as fixing the existing one. So if you can find a better option, please be my guest. In the meantime, what do you think about the attached patch? --------------AB214B005BE8D93534916131 Content-Type: text/x-patch; charset=UTF-8; name="no_constants.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="no_constants.diff" diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi index ea16d9ef15..46462162ca 100644 --- a/doc/lispintro/emacs-lisp-intro.texi +++ b/doc/lispintro/emacs-lisp-intro.texi @@ -7317,8 +7317,6 @@ setcar works is to experiment. We will start with the @code{setcar} function. @need 1200 -@cindex constant lists -@cindex mutable lists First, we can make a list and then set the value of a variable to the list, using the @code{setq} special form. Because we intend to use @code{setcar} to change the list, this @code{setq} should not use the @@ -7327,8 +7325,7 @@ setcar tried to change part of the program while running it. Generally speaking an Emacs Lisp program's components should be constant (or unchanged) while the program is running. So we instead construct an -animal list that is @dfn{mutable} (or changeable) by using the -@code{list} function, as follows: +animal list by using the @code{list} function, as follows: @smallexample (setq animals (list 'antelope 'giraffe 'lion 'tiger)) diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi index bba1b63115..8abdd6663f 100644 --- a/doc/lispref/elisp.texi +++ b/doc/lispref/elisp.texi @@ -297,7 +297,7 @@ Top * Circular Objects:: Read syntax for circular structure. * Type Predicates:: Tests related to types. * Equality Predicates:: Tests of equality between any two objects. -* Constants and Mutability:: Whether an object's value can change. +* Dangerous Mutations:: Objects which should not be modified. Programming Types diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi index baddce4d9c..786c2f2de4 100644 --- a/doc/lispref/eval.texi +++ b/doc/lispref/eval.texi @@ -158,11 +158,12 @@ Self-Evaluating Forms @end group @end example - A self-evaluating form yields constant conses, vectors and strings, and you -should not attempt to modify their contents via @code{setcar}, @code{aset} or -similar operations. The Lisp interpreter might unify the constants -yielded by your program's self-evaluating forms, so that these -constants might share structure. @xref{Constants and Mutability}. + A self-evaluating form yields a value that becomes part of the +program, and you should not attempt to modify their contents via +@code{setcar}, @code{aset} or similar operations. The Lisp +interpreter might unify the constants yielded by your program's +self-evaluating forms, so that these constants might share structure. +@xref{Dangerous Mutations}. It is common to write numbers, characters, strings, and even vectors in Lisp code, taking advantage of the fact that they self-evaluate. @@ -564,8 +565,6 @@ Quoting @defspec quote object This special form returns @var{object}, without evaluating it. -The returned value is a constant, and should not be modified. -@xref{Constants and Mutability}. @end defspec @cindex @samp{'} for quoting @@ -608,9 +607,9 @@ Quoting Although the expressions @code{(list '+ 1 2)} and @code{'(+ 1 2)} both yield lists equal to @code{(+ 1 2)}, the former yields a -freshly-minted mutable list whereas the latter yields a constant list -built from conses that may be shared with other constants. -@xref{Constants and Mutability}. +freshly-minted new list whereas the latter yields a list +built from conses that may be shared with other values. +@xref{Self-Evaluating Forms}. Other quoting constructs include @code{function} (@pxref{Anonymous Functions}), which causes an anonymous lambda expression written in Lisp @@ -710,7 +709,7 @@ Backquote @end example If a subexpression of a backquote construct has no substitutions or -splices, it acts like @code{quote} in that it yields constant conses, +splices, it acts like @code{quote} in that it yields conses, vectors and strings that should not be modified. @node Eval diff --git a/doc/lispref/lists.texi b/doc/lispref/lists.texi index fcaf4386b1..065853042a 100644 --- a/doc/lispref/lists.texi +++ b/doc/lispref/lists.texi @@ -866,15 +866,14 @@ List Variables @node Modifying Lists @section Modifying Existing List Structure @cindex destructive list operations -@cindex mutable lists You can modify the @sc{car} and @sc{cdr} contents of a cons cell with the primitives @code{setcar} and @code{setcdr}. These are destructive operations because they change existing list structure. -Destructive operations should be applied only to mutable lists, -that is, lists constructed via @code{cons}, @code{list} or similar -operations. Lists created by quoting are constants and should not be -changed by destructive operations. @xref{Constants and Mutability}. +Destructive operations should be applied only to lists constructed via +@code{cons}, @code{list} or similar operations. Lists created by +quoting are part of the program and should not be changed by destructive +operations. @xref{Dangerous Mutations}. @cindex CL note---@code{rplaca} vs @code{setcar} @quotation @@ -911,7 +910,7 @@ Setcar @example @group -(setq x (list 1 2)) ; @r{Create a mutable list.} +(setq x (list 1 2)) @result{} (1 2) @end group @group @@ -931,7 +930,7 @@ Setcar @example @group -;; @r{Create two mutable lists that are partly shared.} +;; @r{Create two lists that are partly shared.} (setq x1 (list 'a 'b 'c)) @result{} (a b c) (setq x2 (cons 'z (cdr x1))) @@ -1022,11 +1021,11 @@ Setcdr @example @group -(setq x (list 1 2 3)) ; @r{Create a mutable list.} +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group -(setcdr x '(4)) ; @r{Modify the list's tail to be a constant list.} +(setcdr x '(4)) @result{} (4) @end group @group @@ -1135,11 +1134,11 @@ Rearrangement @example @group -(setq x (list 1 2 3)) ; @r{Create a mutable list.} +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group -(nconc x '(4 5)) ; @r{Modify the list's tail to be a constant list.} +(nconc x '(4 5)) @result{} (1 2 3 4 5) @end group @group @@ -1168,7 +1167,7 @@ Rearrangement @end group @end example -However, the other arguments (all but the last) should be mutable lists. +However, the other arguments (all but the last) must be lists. A common pitfall is to use a constant list as a non-last argument to @code{nconc}. If you do this, the resulting behavior diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 1d5b2c690f..9fdcb4b1bc 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -46,10 +46,6 @@ Lisp Data Types Lisp variables can only take on values of a certain type. @xref{Variables with Restricted Values}.) - Some Lisp objects are @dfn{constant}: their values should never change. -Others are @dfn{mutable}: their values can be changed via destructive -operations that involve side effects. - This chapter describes the purpose, printed representation, and read syntax of each of the standard types in GNU Emacs Lisp. Details on how to use these types can be found in later chapters. @@ -63,7 +59,7 @@ Lisp Data Types * Circular Objects:: Read syntax for circular structure. * Type Predicates:: Tests related to types. * Equality Predicates:: Tests of equality between any two objects. -* Constants and Mutability:: Whether an object's value can change. +* Dangerous Mutations:: Objects which should not be modified. @end menu @node Printed Representation @@ -2379,51 +2375,34 @@ Equality Predicates @end example @end defun -@node Constants and Mutability -@section Constants and Mutability -@cindex constants -@cindex mutable objects - - Some Lisp objects are constant: their values should never change -during a single execution of Emacs running well-behaved Lisp code. -For example, you can create a new integer by calculating one, but you -cannot modify the value of an existing integer. - - Other Lisp objects are mutable: it is safe to change their values -via destructive operations involving side effects. For example, an -existing marker can be changed by moving the marker to point to -somewhere else. +@node Dangerous Mutations +@section Dangerous Mutations - Although all numbers are constants and all markers are -mutable, some types contain both constant and mutable members. These -types include conses, vectors, strings, and symbols. For example, the string -literal @code{"aaa"} yields a constant string, whereas the function -call @code{(make-string 3 ?a)} yields a mutable string that can be -changed via later calls to @code{aset}. + Most Lisp programs first create some values, then mutate them. For +this to work well, a new value should generally be created every time +a function is called. When a value is created using a function such +as @code{list}, @code{cons}, @code{make-string} or +@code{copy-sequence}, that happens reliably, and such a value is safe +to modify. - A mutable object can become constant if it is part of an expression -that is evaluated. The reverse does not occur: constant objects -should stay constant. + Modifying the values obtained by evaluating a self-evaluating form +(such as @code{"abc"}) is not advised. Values that appear as part of +a program should not be modified. Trying to modify a constant variable signals an error -(@pxref{Constant Variables}). -A program should not attempt to modify other types of constants because the -resulting behavior is undefined: the Lisp interpreter might or might -not detect the error, and if it does not detect the error the -interpreter can behave unpredictably thereafter. Another way to put -this is that although mutable objects are safe to change and constant -variables reliably prevent attempts to change them, other constants -are not safely mutable: if a misbehaving program tries to change such a -constant then the constant's value might actually change, or the -program might crash or worse. This problem occurs -with types that have both constant and mutable members, and that have -mutators like @code{setcar} and @code{aset} that are valid on mutable -objects but hazardous on constants. - - When the same constant occurs multiple times in a program, the Lisp -interpreter might save time or space by reusing existing constants or -constant components. For example, @code{(eq "abc" "abc")} returns +(@pxref{Constant Variables}). The current version of Emacs might not +signal an error when a dangerous mutation occurs, however. The result +is essentially undefined: the Lisp interpreter might or might not +detect the error, and if it does not detect the error the interpreter +can behave unpredictably thereafter. If a misbehaving program tries +to change such a value then it might actually succeed, or the program +might crash or worse. This will hopefully be improved in future +versions of Emacs. + + When the same literal occurs 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 @code{t} if the interpreter creates only one instance of the string -constant @code{"abc"}, and returns @code{nil} if it creates two -instances. Lisp programs should be written so that they work -regardless of whether this optimization is in use. +@code{"abc"}, and returns @code{nil} if it creates two instances. +Lisp programs should be written so that they work regardless of +whether this optimization is in use. diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi index 1cb0d05cc7..e41ce2ebe2 100644 --- a/doc/lispref/sequences.texi +++ b/doc/lispref/sequences.texi @@ -183,11 +183,11 @@ Sequence Functions @example @group -(setq bar (list 1 2)) ; @r{Create a mutable list.} +(setq bar (list 1 2)) @result{} (1 2) @end group @group -(setq x (vector 'foo bar)) ; @r{Create a mutable vector.} +(setq x (vector 'foo bar)) @result{} [foo (1 2)] @end group @group @@ -278,7 +278,7 @@ Sequence Functions @example @group -(setq x (list 'a 'b 'c)) ; @r{Create a mutable list.} +(setq x (list 'a 'b 'c)) @result{} (a b c) @end group @group @@ -320,7 +320,7 @@ Sequence Functions For the vector, it is even simpler because you don't need setq: @example -(setq x (copy-sequence [1 2 3 4])) ; @r{Create a mutable vector.} +(setq x (copy-sequence [1 2 3 4])) @result{} [1 2 3 4] (nreverse x) @result{} [4 3 2 1] @@ -330,7 +330,7 @@ Sequence Functions Note that unlike @code{reverse}, this function doesn't work with strings. Although you can alter string data by using @code{aset}, it is strongly -encouraged to treat strings as immutable even when they are mutable. +encouraged to treat strings as immutable. @end defun @@ -374,7 +374,7 @@ Sequence Functions @example @group -(setq nums (list 1 3 2 6 5 4 0)) ; @r{Create a mutable list.} +(setq nums (list 1 3 2 6 5 4 0)) @result{} (1 3 2 6 5 4 0) @end group @group @@ -1228,7 +1228,7 @@ Array Functions @example @group -(setq w (vector 'foo 'bar 'baz)) ; @r{Create a mutable vector.} +(setq w (vector 'foo 'bar 'baz)) @result{} [foo bar baz] (aset w 0 'fu) @result{} fu @@ -1237,7 +1237,7 @@ Array Functions @end group @group -;; @r{@code{copy-sequence} creates a mutable string.} +;; @r{@code{copy-sequence} copies the string to be modified later.} (setq x (copy-sequence "asdfasfd")) @result{} "asdfasfd" (aset x 3 ?Z) @@ -1247,10 +1247,6 @@ Array Functions @end group @end example -The @var{array} should be mutable; that is, it should not be a constant, -such as the constants created via quoting or via self-evaluating forms. -@xref{Constants and Mutability}. - If @var{array} is a string and @var{object} is not a character, a @code{wrong-type-argument} error results. The function converts a unibyte string to multibyte if necessary to insert a character. @@ -1262,7 +1258,6 @@ Array Functions @example @group -;; @r{Create a mutable vector and then fill it with zeros.} (setq a (copy-sequence [a b c d e f g])) @result{} [a b c d e f g] (fillarray a 0) @@ -1271,7 +1266,6 @@ Array Functions @result{} [0 0 0 0 0 0 0] @end group @group -;; @r{Create a mutable string and then fill it with "-".} (setq s (copy-sequence "When in the course")) @result{} "When in the course" (fillarray s ?-) @@ -1309,9 +1303,7 @@ Vectors A vector, like a string or a number, is considered a constant for evaluation: the result of evaluating it is the same vector. This does not evaluate or even examine the elements of the vector. -@xref{Self-Evaluating Forms}. Vectors written with square brackets -are constants and should not be modified via @code{aset} or other -destructive operations. @xref{Constants and Mutability}. +@xref{Self-Evaluating Forms}. Here are examples illustrating these principles: diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi index a4c9c2549c..3a6de56584 100644 --- a/doc/lispref/strings.texi +++ b/doc/lispref/strings.texi @@ -51,8 +51,7 @@ String Basics operate on them with the general array and sequence functions documented in @ref{Sequences Arrays Vectors}. For example, you can access or change individual characters in a string using the functions @code{aref} -and @code{aset} (@pxref{Array Functions}). However, you should not -try to change the contents of constant strings (@pxref{Modifying Strings}). +and @code{aset} (@pxref{Array Functions}). There are two text representations for non-@acronym{ASCII} characters in Emacs strings (and in buffers): unibyte and multibyte. @@ -383,8 +382,8 @@ Modifying Strings You can alter the contents of a mutable string via operations described in this section. However, you should not try to use these -operations to alter the contents of a constant string. -@xref{Constants and Mutability}. +operations to alter the contents of a string literal. +@xref{Dangerous Mutations}. The most basic way to alter the contents of an existing string is with @code{aset} (@pxref{Array Functions}). @code{(aset @var{string} --------------AB214B005BE8D93534916131-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 May 2020 06:10: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 To: Dmitry Gutov , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15886589685619 (code B ref 40671); Tue, 05 May 2020 06:10:01 +0000 Received: (at 40671) by debbugs.gnu.org; 5 May 2020 06:09:28 +0000 Received: from localhost ([127.0.0.1]:34613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVqlk-0001SZ-EV for submit@debbugs.gnu.org; Tue, 05 May 2020 02:09:28 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45654) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVqli-0001SJ-9W for 40671@debbugs.gnu.org; Tue, 05 May 2020 02:09:26 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CE616160065; Mon, 4 May 2020 23:09:20 -0700 (PDT) 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 1pJhgdb77N0v; Mon, 4 May 2020 23:09:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 193DE160079; Mon, 4 May 2020 23:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 lXll5lXkx0wk; Mon, 4 May 2020 23:09:19 -0700 (PDT) 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 CF00F160065; Mon, 4 May 2020 23:09:19 -0700 (PDT) References: <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <0c7570cb-bf52-a617-bf54-27a47c54e04a@cs.ucla.edu> Date: Mon, 4 May 2020 23:09:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/4/20 6:39 PM, Dmitry Gutov wrote: > if we just make it a literal: > > (let ((x '(0 . 0))) (setcar x 1)) > > ...it also becomes okay to modify it No, because the literal might be placed in read-only storage of some sort. > In the meantime, what do you think about the attached patch? Most of it is OK, but it goes too far in removing useful practical advice about not doing "dangerous mutations" (to use the terminology you prefer). The defspec for quote, the defuns for aset, setcar and setcdr, and the square-bracket notation for vectors, should all point to the Dangerous Mutations section. Also, the section on Dangerous Mutations should not imply that self-evaluating forms are the only way to get objects that are dangerous to mutate, as there are other ways to get such objects. The section Dangerous Mutations is really about Mutations, not merely about Dangerous Mutations. For example, it talks about modifying constant variables. So I suggest changing its name to just "Mutations". This will help us in future versions of Emacs, in which at least some of these mutations should become non-dangerous. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 May 2020 12:39: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 To: Paul Eggert , Drew Adams Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158868229320429 (code B ref 40671); Tue, 05 May 2020 12:39:02 +0000 Received: (at 40671) by debbugs.gnu.org; 5 May 2020 12:38:13 +0000 Received: from localhost ([127.0.0.1]:34987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVwpx-0005JQ-H2 for submit@debbugs.gnu.org; Tue, 05 May 2020 08:38:13 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:35972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVwpw-0005JD-8g for 40671@debbugs.gnu.org; Tue, 05 May 2020 08:38:12 -0400 Received: by mail-wr1-f50.google.com with SMTP id z8so1626158wrw.3 for <40671@debbugs.gnu.org>; Tue, 05 May 2020 05:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TiURPeP3nwXlHlq0VPim63ziBlxrmLx2WzEqET1rtUQ=; b=s3QBfgdWdr05uJ1A6b3rVGZKsh1SIraV/IQr2yCaoU5EPFIduXcI6+4BTIwLuS83Os VsBUP7Bde/u1rFXhsdxWIB6zNvopxlik+kdfKzAb3T68JQp0p61Q4/WvBRwNcP1y0+4O yyyS3yJP1ktPRBUG5sySEitxkoqsxFeaUvlBBHtg8QEoR/GhEzj5oLrr+zC3aExlIPcS KDmO4gfCN0Wjq1Zo8geDDe0TWViIIKhfw1UCIEqIzlQ9xkTZIjDnwFQPNX4OcAmlsID2 5W5gvnti7Lbvhx00OcYw8QKe0zlq44wK+15jduuFNFNXwGQ86sGUXDXV5xAkRfzKCStt 2MXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TiURPeP3nwXlHlq0VPim63ziBlxrmLx2WzEqET1rtUQ=; b=OBbFG3Qn0scyCqpcQDuVG0myKsBfJMaS81HFGcKfxHvLkcOmLmNw3pCpUuxZOK+9bZ GT5YRN5OX7uMafL/Z66gIp7mP3n6BqDivxERtwaHuDV+dp986zpMqduAf78WF5CR5l2G Pv4CnXC0MwNmaUxxnU3KKMTp0rVWo5t/fdKAVQJVhIFi6cNPjyRRko+2v9+x2CvJR+jC /PcQmk7MLq7RBpiIt90tUMSQdItKzJfA3AKBppvGcwrQUC6Sndk1CBn4TYR6maWy3TZx JgyGE+HpGE5cPv1NK5ZoOOFzxPhp8hFJjYr1R0126Xtr5gdEkUEDXnaDSLZskJZBZTNZ /P7g== X-Gm-Message-State: AGi0PuZI2T6pQ+gez6TKa43lh+JK7xXO++DaF+0Mty26U5kgfKP1YLjB 7avlWXl5aBH4Q9Adz/C1guI= X-Google-Smtp-Source: APiQypIzUHc9OrV/omRqx+YTf8aIb7fFcYNWQLQBzvYWPz3MK0DcJOYaQkGXjmuyFcfmCQlA6anrFg== X-Received: by 2002:adf:e44b:: with SMTP id t11mr3798254wrm.188.1588682286395; Tue, 05 May 2020 05:38:06 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a1sm2817842wrn.80.2020.05.05.05.38.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 May 2020 05:38:05 -0700 (PDT) References: <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> From: Dmitry Gutov Message-ID: Date: Tue, 5 May 2020 15:38:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <0c7570cb-bf52-a617-bf54-27a47c54e04a@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 05.05.2020 09:09, Paul Eggert wrote: >> In the meantime, what do you think about the attached patch? > > Most of it is OK, but it goes too far in removing useful practical advice about > not doing "dangerous mutations" (to use the terminology you prefer). The defspec > for quote, the defuns for aset, setcar and setcdr, and the square-bracket > notation for vectors, should all point to the Dangerous Mutations section. I think that was too much: we've been living with this problem for many years without hitting it too often. Sticking warning all over seems like an overreaction. > Also, the section on Dangerous Mutations should not imply that self-evaluating > forms are the only way to get objects that are dangerous to mutate, as there are > other ways to get such objects. I thought your explanation was a bit too vague, so I added concreteness. In essence though it was saying constants this and constants that, but the actual examples were also only about self-evaluating forms. Did I delete some informative part? > The section Dangerous Mutations is really about Mutations, not merely about > Dangerous Mutations. For example, it talks about modifying constant variables. > So I suggest changing its name to just "Mutations". This will help us in future > versions of Emacs, in which at least some of these mutations should become > non-dangerous. It's talking about the cases where a modification shouldn't occur, hence the name. When something from the list becomes legal, I think this section will just stop mentioning it? In any case, none of my objections here are strong ones. How about you take the proposed patch and update it as you see fit? As long as "constant values" don't make a comeback, I'm good. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 May 2020 17:42: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 To: Paul Eggert , Dmitry Gutov Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158870049623669 (code B ref 40671); Tue, 05 May 2020 17:42:01 +0000 Received: (at 40671) by debbugs.gnu.org; 5 May 2020 17:41:36 +0000 Received: from localhost ([127.0.0.1]:37311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW1ZP-00069W-Pg for submit@debbugs.gnu.org; Tue, 05 May 2020 13:41:36 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:53866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW1ZO-00069I-EQ for 40671@debbugs.gnu.org; Tue, 05 May 2020 13:41:26 -0400 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 045HXMQP138792; Tue, 5 May 2020 17:41:07 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=HHshZFXk+GCtJtrojMLYKiNlBqc8dOHsgbXnINYutfk=; b=lpRMNf70GPg+EUOiKaCBwwyC0WyQw2YDm2EHi22ndojz/qnVnb7mA/KD5nIUyVe23+NF pV2AVJpgwZydx8AaOk/J0tms29w+8XwGIyQLtNbwncB8l8odp+R63y82KQs4S2cpPorv kWpIhVNmojyR2bzhoMoRLwXVGleGH48a7jm801zZeeRfiUH92s9snVoJzzbVhMUXkcvS e2we9VcidQJ7nzQsjB/oaAk0YXm2tt410/KT8T9dVpQk+rfdcjAx+SyyZZ41ObRSoS7W Vaip5sooWkr43kL/zyFM0nRvwA9fGzLZsv+qhioZO8qTskdJnBJ9M7GuP8R6NrbBWxuO vA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 30s0tme6sb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 05 May 2020 17:41:07 +0000 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 045HasqS092566; Tue, 5 May 2020 17:41:07 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 30sjdtg8kr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 05 May 2020 17:41:07 +0000 Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 045Hf0Kp000881; Tue, 5 May 2020 17:41:00 GMT MIME-Version: 1.0 Message-ID: <329bbcc4-aaa7-4deb-a880-47a26e12aa26@default> Date: Tue, 5 May 2020 10:40:59 -0700 (PDT) From: Drew Adams References: <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> In-Reply-To: <0c7570cb-bf52-a617-bf54-27a47c54e04a@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9612 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=18 mlxscore=0 bulkscore=0 adultscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005050133 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9612 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 suspectscore=18 phishscore=0 clxscore=1015 bulkscore=0 mlxlogscore=999 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005050133 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Apologies for chiming in here again. And I haven't read the proposed text or followed the thread recently. But I just saw "Dangerous Mutations". I really don't think that it's helpful or appropriate to speak of danger in the context of the gotcha we've been discussing. Danger is danger. Yes, with undefined behavior, and with possible modification of list structure etc., there is the possibility of loss of data, and that's not a good thing. Undefined is scary. But I'm not in favor of crying "DANGER" about such things. At all. Check the Common Lisp doc. You don't find such screaming warnings plastered throughout, whenever it comes to destructive modification. The word "destructive" is sufficiently strong. And in the case of the gotchas being discussed it's not necessarily even destructive modification. The unknown/undefined is just that. No need (and inappropriate) to wrap it DANGEROUS! Just one opinion. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 May 2020 18:50: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 To: Drew Adams , Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158870455930538 (code B ref 40671); Tue, 05 May 2020 18:50:02 +0000 Received: (at 40671) by debbugs.gnu.org; 5 May 2020 18:49:19 +0000 Received: from localhost ([127.0.0.1]:37447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW2d5-0007wU-6U for submit@debbugs.gnu.org; Tue, 05 May 2020 14:49:19 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:39545) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW2d4-0007w4-26 for 40671@debbugs.gnu.org; Tue, 05 May 2020 14:49:18 -0400 Received: by mail-wr1-f51.google.com with SMTP id l18so3975590wrn.6 for <40671@debbugs.gnu.org>; Tue, 05 May 2020 11:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rrCxWNMz0L+of59l33BKXw3ftapv+KR6yGO4SxlFoTw=; b=Hjf5glnWb4n47b7zF0ITD2Fw98epJMWdYmXVI7qQgzElFzwQhnq6ZJM0ECpdFB3qdk nD8ZpDLPXRHcwkATCSofGvYlvsnC9hRhupJG39Zyz9dy8pYcpJ5b1eYCnvzyQJNW/xZi Jno9CxgBCY0f0oAIf9GM5zDafGbP2OkVTLfnw91MvJUH2OiVrmEHgG7wSBe1bgaXXGGX iFB+pWtfWSJ2Wgovk7X9XbwJCgOpiavT18e9JkGgX+rG01i6nYp+emX/J+wju9P3qpSe KlwLWBvP3q4acEeFmDwfQ0hhE69mTgpIp7FKoCERb5PdEmLPhVBGde/8FKjyDPihYbVP KEbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rrCxWNMz0L+of59l33BKXw3ftapv+KR6yGO4SxlFoTw=; b=jEcaLRv6ioUj/QIvfn2/HJBBMp4XEUtW3WyMDxhnjR7rAO1EO4DWVSumSmztZ7pWnM 5WI+UsMlDg+7pGsRwwLPriV8cIF8Nf8aSsMRYHQwPqTdReup2E8yD8Z5qGg6Z/IeveJv tSFQdtlvvPJvCHfMR8zlV0359LSQeVGTvMFN85YXEsRLUOwruyF5JHeteMzkoUyEBKrK OMngOcRfVBdx1oWFe8vMfZcuY+YrZ6YBer/ZBlfdrfM7uHEOMSPCoep+h9Oyn0z/j65/ gCC/Axl7Egsmo+S9jPK5/kbQxjtFgOjYLcHdx+NeTp+h5fyID58qSCxJezRVeAoMc8we I+JA== X-Gm-Message-State: AGi0PuaHj6AeFiOffMJ4Q4PSmeKJE1diNPFP88rNdi4pdXmhYEAL3X4n PpCiMMnmmTVxkn99rKLlrcyvpgcB X-Google-Smtp-Source: APiQypLz/ycDrw/etJ5YvTD65jl+Y1IfutV3uw4uNC0nSJPtY10YgtpJ8w0DIoSFKCGRocYo+apeMQ== X-Received: by 2002:a5d:4389:: with SMTP id i9mr5450642wrq.374.1588704552396; Tue, 05 May 2020 11:49:12 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 17sm4856906wmo.2.2020.05.05.11.49.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 May 2020 11:49:11 -0700 (PDT) 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> <329bbcc4-aaa7-4deb-a880-47a26e12aa26@default> From: Dmitry Gutov Message-ID: Date: Tue, 5 May 2020 21:49:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <329bbcc4-aaa7-4deb-a880-47a26e12aa26@default> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 05.05.2020 20:40, Drew Adams wrote: > The word "destructive" is sufficiently strong. > And in the case of the gotchas being discussed > it's not necessarily even destructive > modification. It's not modification if it's not destructive. At least, in the context of the problem we're trying to describe. Destructive modification, by itself, is a very regular occasion. Not something to warn against. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 May 2020 19: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 To: Dmitry Gutov , Paul Eggert Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , ke.vigouroux@laposte.net Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158870691718247 (code B ref 40671); Tue, 05 May 2020 19:29:01 +0000 Received: (at 40671) by debbugs.gnu.org; 5 May 2020 19:28:37 +0000 Received: from localhost ([127.0.0.1]:37573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW3F6-0004kE-QL for submit@debbugs.gnu.org; Tue, 05 May 2020 15:28:36 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:58616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW3F4-0004k2-Rh for 40671@debbugs.gnu.org; Tue, 05 May 2020 15:28:35 -0400 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 045JN78E132568; Tue, 5 May 2020 19:28:25 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=lRiNZGZk6L606O/UYYoedYcdqr1QPgM+sJ7DDYMw37g=; b=EqpXnGHLEIMPIeYnyVjYjkxubfplYH3+VOsCpYCCQFpdy8/UCMS9ug9UQfxPzIlJjoSe MhuQlXyz4VOyuGfHzIiY7hfHE1Lgd2ydHsTYMFpqlLrzMjtBbt9XEcoDH13O+Uroz/IM FZyRYt1n5ruEZv4SFPlt8kiNICJd0DC+AbNePYA0Zrr+5i0BipPn8FJDSqfDdWK0dSMQ iHLZ4wes2Kro4yXprWVUYI8HkfOt36G3s1TUh3m4SJr625mpAcC657RFdHEyiU6wkcXp cvW8OYHiWpeWhJ7O2zs9himdKxTR1k33l3ftaGnIsNvSAO76jlng9RssIfSomimGzL3+ vA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 30s0tmepj9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 05 May 2020 19:28:25 +0000 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 045JMwes084998; Tue, 5 May 2020 19:26:25 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 30sjdtnwbk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 05 May 2020 19:26:23 +0000 Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 045JQBGm032670; Tue, 5 May 2020 19:26:12 GMT MIME-Version: 1.0 Message-ID: <532da3ce-558a-4d9c-93b6-c517c6e44262@default> Date: Tue, 5 May 2020 12:26:11 -0700 (PDT) From: Drew Adams 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> <329bbcc4-aaa7-4deb-a880-47a26e12aa26@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9612 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=18 mlxscore=0 bulkscore=0 adultscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005050147 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9612 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 suspectscore=18 phishscore=0 clxscore=1015 bulkscore=0 mlxlogscore=999 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005050147 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > It's not modification if it's not destructive. At least, in the context > of the problem we're trying to describe. >=20 > Destructive modification, by itself, is a very regular occasion. Not > something to warn against. Whatever. My point is that there's no need to scream "Danger!". A warning does not imply danger. And a tip about a gotcha is not necessarily even a warning. Can the consequences ever be awful? Presumably. Will they often be awful? Not likely. The most likely negative effect is spending time trying to figure out what's happening. That's why we should have a tip about the gotcha. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Kevin Vigouroux Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 May 2020 21:37: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 To: Paul Eggert Cc: Richard Stallman , Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15887145787415 (code B ref 40671); Tue, 05 May 2020 21:37:01 +0000 Received: (at 40671) by debbugs.gnu.org; 5 May 2020 21:36:18 +0000 Received: from localhost ([127.0.0.1]:37774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW5Ed-0001vU-K8 for submit@debbugs.gnu.org; Tue, 05 May 2020 17:36:18 -0400 Received: from smtpoutz26.laposte.net ([194.117.213.101]:56935 helo=smtp.laposte.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW4Uo-0000TX-FZ for 40671@debbugs.gnu.org; Tue, 05 May 2020 16:48:55 -0400 Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout014 (Postfix) with ESMTP id D2E153000ED for <40671@debbugs.gnu.org>; Tue, 5 May 2020 22:48:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=laposte.net; s=mail0; t=1588711732; bh=IZN6UW9H05YGFCzHqwdZpGPP4HztqzYeGgKanRKOyqE=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=RI8phLiFmKZ74qwBlUjb71ntyf5HTe2h1qWLknXupqOPCP0SX004J5DifrSXAkO0O 8V8/EqFNVPlNWU1HLgy/JZ1NjJ2TkvMfU7k88KMPsz1xxmLAQF526+GQqC47IJUFJC tAYMseBXErnXRC2VFvqS1OY5fwKutfO+pMy1IXOZs21fkUMoH85yTL/I8o38LnK+qH MqoGovBDDEvZl43bFrKsMSmNHC3R3FflzC4BjUXOoqzqK/z9LOj9RH1HhUIZRcKsPw CMKNhUhaVFRiNVj1O4p8g9j/wHk1+x873vLUx9hEBy7i9OmlFcjR0yIS8VVtCWNJSH pKQSq/+bsspKA== Received: from mlpnf0116.laposte.net (unknown [10.94.128.95]) by lpn-prd-vrout014 (Postfix) with ESMTP id CC4E53000E8 for <40671@debbugs.gnu.org>; Tue, 5 May 2020 22:48:52 +0200 (CEST) Received: from outgoing-mail.laposte.net (localhost.localdomain [127.0.0.1]) by mlpnf0102.laposte.net (SMTP Server) with ESMTP id 49GsJZ0sFTz7t7l; Tue, 5 May 2020 22:48:46 +0200 (CEST) X-mail-filterd: 0.4.0.2 X-mail-filterd: 0.4.0.2 X-lpn-spamrating: 36 X-lpn-spamlevel: not-spam X-lpn-spamcause: OK, (-100)(0000)gggruggvucftvghtrhhoucdtuddrgeduhedrjeejgdduhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfntefrqffuvffgpdfqfgfvpdggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufhffjgfkfgggtgesthdtredttdertdenucfhrhhomhepmfgvvhhinhcugghighhouhhrohhugicuoehkvgdrvhhighhouhhrohhugieslhgrphhoshhtvgdrnhgvtheqnecuggftrfgrthhtvghrnhepgfeuleehveeugfeiudeuhedvieefffejfeeukefftdefteevudegteelgfffteejnecukfhppeeltddrfedvrdduudefrddvfeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepsghluhgvmhgrnhdpihhnvghtpeeltddrfedvrdduudefrddvfeeipdhmrghilhhfrhhomhepkhgvrdhvihhgohhurhhouhigsehlrghpohhsthgvrdhnvghtpdhrtghpthhtoheprhhmshesghhnuhdrohhrghdprhgtphhtthhopeegtdeijeduseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepmhgrthhtihgrshgvsegrtghmrdhorhhgpdhrtghpthhtohepmhhitghhrggvlhgphhgvvghruggvghgvnhesfigvsgdruggvpdhrtghpthhtohepughrvgifrdgruggrmhhssehorhgrtghlvgdrtghomhdprhgtphhtthhopegughhuthhovheshigrnhguvgigr dhruhdprhgtphhtthhopegvghhgvghrthestghsrdhutghlrgdrvgguuh X-lpn-mailing: LEGIT Received: from blueman (arennes-256-1-114-236.w90-32.abo.wanadoo.fr [90.32.113.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mlpnf0102.laposte.net (SMTP Server) with ESMTPSA id 49GsJY1Snfz7t7m; Tue, 5 May 2020 22:48:45 +0200 (CEST) From: Kevin Vigouroux References: <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> Date: Tue, 05 May 2020 22:48:44 +0200 In-Reply-To: <2ca64f28-1255-4135-6e45-0f0e12b9e72d@cs.ucla.edu> (Paul Eggert's message of "Mon, 4 May 2020 10:52:18 -0700") Message-ID: <87a72mumz7.fsf@laposte.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Mailman-Approved-At: Tue, 05 May 2020 17:36:14 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > On 5/4/20 3:16 AM, Dmitry Gutov wrote: >> On 04.05.2020 02:10, Paul Eggert wrote: >>> The term you used was "Objects referenced from executable code". But that term >>> includes pretty much every object used in Elisp, at least until the object >>> becomes unreachable and is garbage-collected. >> >> I see. Could you present a specific counter-example, however? >> >> One where the phrasing "referenced from executable code" would apply, but "part >> of expressions that are evaluated" wouldn't. > > Pretty much any ordinary cons will do. In (let ((x (cons 0 0))) (setcar x 1)), > for example, the cons is referenced from executable code but it's OK to modify > the cons. The cons becomes unreachable when the 'let' finishes. The cons is not > part of any expression that is evaluated. > > The problem here evidently is one of terminology, not of understanding the > underlying issues. When I read "Objects referenced from executable code" I > evidently got a different meaning than what you intended. These things happen > when introducing a new terminology. Would the expression "constant form" be appropriate? Here is the definition given in the CLHS (in the glossary). Constant form: Any form for which evaluation always yields the same value, that neither affects nor is affected by the environment in which it is evaluated (except that is permitted to refer to the names of constant variables defined in the environment), and that neither affects nor is affected by the state of any object except those objects that are otherwise inaccessible parts of objects created by the form itself. For instance, a car form in which the argument is a quote form is a constant form. If I understand correctly, the problem is partially related to self-modifying code. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 May 2020 05:58: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 To: Kevin Vigouroux Cc: Richard Stallman , Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158900386223864 (code B ref 40671); Sat, 09 May 2020 05:58:01 +0000 Received: (at 40671) by debbugs.gnu.org; 9 May 2020 05:57:42 +0000 Received: from localhost ([127.0.0.1]:46663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXIUY-0006Cp-5P for submit@debbugs.gnu.org; Sat, 09 May 2020 01:57:42 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58008) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXIUV-0006Cb-TQ for 40671@debbugs.gnu.org; Sat, 09 May 2020 01:57:40 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A15971600C3; Fri, 8 May 2020 22:57:33 -0700 (PDT) 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 pc2Jf7rbA-Pw; Fri, 8 May 2020 22:57:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EC6031600CD; Fri, 8 May 2020 22:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 C3xp513HiHAk; Fri, 8 May 2020 22:57:32 -0700 (PDT) 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 A23FC1600C3; Fri, 8 May 2020 22:57:32 -0700 (PDT) References: <278a1350-8b9e-4f3b-854a-723d578129f3@default> <6cbe3c10-6d81-f2be-30d7-17096b3f3517@yandex.ru> <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> <87a72mumz7.fsf@laposte.net> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Fri, 8 May 2020 22:57:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87a72mumz7.fsf@laposte.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/5/20 1:48 PM, Kevin Vigouroux wrote: > Would the expression "constant form" be appropriate? Not exactly, as that refers to a form in the source code, whereas we are talking about objects available at run-time. There is overlap between the two concepts but some objects are "constant" (in the sense of the current emacs-27 doc) without appearing in the source code. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 May 2020 06:11: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 To: Dmitry Gutov Cc: ke.vigouroux@laposte.net, Richard Stallman , Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158900463225090 (code B ref 40671); Sat, 09 May 2020 06:11:01 +0000 Received: (at 40671) by debbugs.gnu.org; 9 May 2020 06:10:32 +0000 Received: from localhost ([127.0.0.1]:46667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXIgx-0006Wb-J1 for submit@debbugs.gnu.org; Sat, 09 May 2020 02:10:32 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXIgw-0006WO-1s for 40671@debbugs.gnu.org; Sat, 09 May 2020 02:10:31 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E99CC1600C3; Fri, 8 May 2020 23:10:23 -0700 (PDT) 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 G-58ACAXLeQw; Fri, 8 May 2020 23:10:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E4F871600CD; Fri, 8 May 2020 23:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 I7IsInoaXQ1S; Fri, 8 May 2020 23:10:21 -0700 (PDT) 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 9B7F21600C3; Fri, 8 May 2020 23:10:21 -0700 (PDT) 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> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <04298f7d-f2c0-5186-57d3-522e3d886166@cs.ucla.edu> Date: Fri, 8 May 2020 23:10:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------47B5244C8E6A6AEFF8FB82B3" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------47B5244C8E6A6AEFF8FB82B3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/5/20 5:38 AM, Dmitry Gutov wrote: > In any case, none of my objections here are strong ones. How about you take the > proposed patch and update it as you see fit? As long as "constant values" don't > make a comeback, I'm good. OK, attached is a draft patch to emacs-27. Although it doesn't go as far as your patch, it does keep some of it, and in particular it gets rid of the introduction of the term "constant" to describe objects that should not be changed. It also omits the "Dangerous" that Drew objected to, and gives an example of a term that was formerly mutable but is now something that you should not change. --------------47B5244C8E6A6AEFF8FB82B3 Content-Type: text/plain; charset=UTF-8; name="0001-Don-t-use-constant-for-values-you-shouldn-t-change.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0001-Don-t-use-constant-for-values-you-shouldn-t-change.txt" RnJvbSA3MDJmMjhiZTliZWVhNGEwNDc1MDk0MTQwYWZiODVjZDRhYTM2NmJhIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBGcmksIDggTWF5IDIwMjAgMjI6NTM6NDEgLTA3MDAKU3ViamVjdDogW1BBVENI XSA9P1VURi04P3E/RG9uPUUyPTgwPTk5dD0yMHVzZT0yMD1FMj04MD05Q2NvbnN0YW50Pz0K ID0/VVRGLTg/cT89RTI9ODA9OUQ9MjBmb3I9MjB2YWx1ZXM9MjB5b3U9MjBzaG91bGRuPUUy PTgwPTk5dD0yMGNoYW5nZT89Ck1JTUUtVmVyc2lvbjogMS4wCkNvbnRlbnQtVHlwZTogdGV4 dC9wbGFpbjsgY2hhcnNldD1VVEYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0 CgpJbnNwaXJlZCBieSBwYXRjaCBwcm9wb3NlZCBieSBEbWl0cnkgR3V0b3YgKEJ1ZyM0MDY3 MSMzOTMpLgoqIGRvYy9saXNwaW50cm8vZW1hY3MtbGlzcC1pbnRyby50ZXhpIChzZXRjYXIp OgpEb27igJl0IHB1c2ggbXV0YWJpbGl0eSBoZXJlLgoqIGRvYy9saXNwcmVmL2V2YWwudGV4 aSAoU2VsZi1FdmFsdWF0aW5nIEZvcm1zLCBRdW90aW5nKQooQmFja3F1b3RlKToKKiBkb2Mv bGlzcHJlZi9saXN0cy50ZXhpIChNb2RpZnlpbmcgTGlzdHMpOgoqIGRvYy9saXNwcmVmL29i amVjdHMudGV4aSAoTGlzcCBEYXRhIFR5cGVzLCBNdXRhYmlsaXR5KToKKiBkb2MvbGlzcHJl Zi9zZXF1ZW5jZXMudGV4aSAoQXJyYXkgRnVuY3Rpb25zLCBWZWN0b3JzKToKKiBkb2MvbGlz cHJlZi9zdHJpbmdzLnRleGkgKFN0cmluZyBCYXNpY3MsIE1vZGlmeWluZyBTdHJpbmdzKToK RG9u4oCZdCB1c2UgdGhlIHdvcmQg4oCcY29uc3RhbnTigJ0gdG8gZGVzY3JpYmUgYWxsIHZh bHVlcyB0aGF0CmEgcHJvZ3JhbSBzaG91bGQgbm90IGNoYW5nZS4KKiBkb2MvbGlzcHJlZi9v YmplY3RzLnRleGkgKE11dGFiaWxpdHkpOgpSZW5hbWUgZnJvbSDigJxDb25zdGFudHMgYW5k IE11dGFiaWxpdHnigJ0uICBBbGwgdXNlcyBjaGFuZ2VkLgpJbiBhIGZvb3Rub3RlLCBjb250 cmFzdCB0aGUgRW1hY3MgYmVoYXZpb3Igd2l0aCB0aGF0IG9mIENvbW1vbgpMaXNwLCBQeXRo b24sIGV0Yy4gZm9yIGNsYXJpdHksIGFuZCBzYXkgdGhlIGdvYWwgaXMgdG8gYmUgbmljZXIu Ci0tLQogZG9jL2xpc3BpbnRyby9lbWFjcy1saXNwLWludHJvLnRleGkgfCAgNSArLQogZG9j L2xpc3ByZWYvZWxpc3AudGV4aSAgICAgICAgICAgICAgfCAgMiArLQogZG9jL2xpc3ByZWYv ZXZhbC50ZXhpICAgICAgICAgICAgICAgfCAyMSArKysrKy0tLS0KIGRvYy9saXNwcmVmL2xp c3RzLnRleGkgICAgICAgICAgICAgIHwgMTYgKysrLS0tLQogZG9jL2xpc3ByZWYvb2JqZWN0 cy50ZXhpICAgICAgICAgICAgfCA3MSArKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLQog ZG9jL2xpc3ByZWYvc2VxdWVuY2VzLnRleGkgICAgICAgICAgfCAyNSArKysrKy0tLS0tCiBk b2MvbGlzcHJlZi9zdHJpbmdzLnRleGkgICAgICAgICAgICB8IDExICsrLS0tCiA3IGZpbGVz IGNoYW5nZWQsIDY4IGluc2VydGlvbnMoKyksIDgzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp dCBhL2RvYy9saXNwaW50cm8vZW1hY3MtbGlzcC1pbnRyby50ZXhpIGIvZG9jL2xpc3BpbnRy by9lbWFjcy1saXNwLWludHJvLnRleGkKaW5kZXggZWExNmQ5ZWYxNS4uNDY0NjIxNjJjYSAx MDA2NDQKLS0tIGEvZG9jL2xpc3BpbnRyby9lbWFjcy1saXNwLWludHJvLnRleGkKKysrIGIv ZG9jL2xpc3BpbnRyby9lbWFjcy1saXNwLWludHJvLnRleGkKQEAgLTczMTcsOCArNzMxNyw2 IEBAIHNldGNhcgogd29ya3MgaXMgdG8gZXhwZXJpbWVudC4gIFdlIHdpbGwgc3RhcnQgd2l0 aCB0aGUgQGNvZGV7c2V0Y2FyfSBmdW5jdGlvbi4KIAogQG5lZWQgMTIwMAotQGNpbmRleCBj b25zdGFudCBsaXN0cwotQGNpbmRleCBtdXRhYmxlIGxpc3RzCiBGaXJzdCwgd2UgY2FuIG1h a2UgYSBsaXN0IGFuZCB0aGVuIHNldCB0aGUgdmFsdWUgb2YgYSB2YXJpYWJsZSB0byB0aGUK IGxpc3QsIHVzaW5nIHRoZSBAY29kZXtzZXRxfSBzcGVjaWFsIGZvcm0uICBCZWNhdXNlIHdl IGludGVuZCB0byB1c2UKIEBjb2Rle3NldGNhcn0gdG8gY2hhbmdlIHRoZSBsaXN0LCB0aGlz IEBjb2Rle3NldHF9IHNob3VsZCBub3QgdXNlIHRoZQpAQCAtNzMyNyw4ICs3MzI1LDcgQEAg c2V0Y2FyCiB0cmllZCB0byBjaGFuZ2UgcGFydCBvZiB0aGUgcHJvZ3JhbSB3aGlsZSBydW5u aW5nIGl0LiAgR2VuZXJhbGx5CiBzcGVha2luZyBhbiBFbWFjcyBMaXNwIHByb2dyYW0ncyBj b21wb25lbnRzIHNob3VsZCBiZSBjb25zdGFudCAob3IKIHVuY2hhbmdlZCkgd2hpbGUgdGhl IHByb2dyYW0gaXMgcnVubmluZy4gIFNvIHdlIGluc3RlYWQgY29uc3RydWN0IGFuCi1hbmlt YWwgbGlzdCB0aGF0IGlzIEBkZm57bXV0YWJsZX0gKG9yIGNoYW5nZWFibGUpIGJ5IHVzaW5n IHRoZQotQGNvZGV7bGlzdH0gZnVuY3Rpb24sIGFzIGZvbGxvd3M6CithbmltYWwgbGlzdCBi eSB1c2luZyB0aGUgQGNvZGV7bGlzdH0gZnVuY3Rpb24sIGFzIGZvbGxvd3M6CiAKIEBzbWFs bGV4YW1wbGUKIChzZXRxIGFuaW1hbHMgKGxpc3QgJ2FudGVsb3BlICdnaXJhZmZlICdsaW9u ICd0aWdlcikpCmRpZmYgLS1naXQgYS9kb2MvbGlzcHJlZi9lbGlzcC50ZXhpIGIvZG9jL2xp c3ByZWYvZWxpc3AudGV4aQppbmRleCBiYmExYjYzMTE1Li45YTY3OTY3OTBjIDEwMDY0NAot LS0gYS9kb2MvbGlzcHJlZi9lbGlzcC50ZXhpCisrKyBiL2RvYy9saXNwcmVmL2VsaXNwLnRl eGkKQEAgLTI5Nyw3ICsyOTcsNyBAQCBUb3AKICogQ2lyY3VsYXIgT2JqZWN0czo6ICAgICAg ICBSZWFkIHN5bnRheCBmb3IgY2lyY3VsYXIgc3RydWN0dXJlLgogKiBUeXBlIFByZWRpY2F0 ZXM6OiAgICAgICAgIFRlc3RzIHJlbGF0ZWQgdG8gdHlwZXMuCiAqIEVxdWFsaXR5IFByZWRp Y2F0ZXM6OiAgICAgVGVzdHMgb2YgZXF1YWxpdHkgYmV0d2VlbiBhbnkgdHdvIG9iamVjdHMu Ci0qIENvbnN0YW50cyBhbmQgTXV0YWJpbGl0eTo6ICBXaGV0aGVyIGFuIG9iamVjdCdzIHZh bHVlIGNhbiBjaGFuZ2UuCisqIE11dGFiaWxpdHk6OiAgICAgICAgICAgICAgU29tZSBvYmpl Y3RzIHNob3VsZCBub3QgYmUgbW9kaWZpZWQuCiAKIFByb2dyYW1taW5nIFR5cGVzCiAKZGlm ZiAtLWdpdCBhL2RvYy9saXNwcmVmL2V2YWwudGV4aSBiL2RvYy9saXNwcmVmL2V2YWwudGV4 aQppbmRleCBiYWRkY2U0ZDljLi4zOWYzNDJhNzk4IDEwMDY0NAotLS0gYS9kb2MvbGlzcHJl Zi9ldmFsLnRleGkKKysrIGIvZG9jL2xpc3ByZWYvZXZhbC50ZXhpCkBAIC0xNTgsMTEgKzE1 OCwxMSBAQCBTZWxmLUV2YWx1YXRpbmcgRm9ybXMKIEBlbmQgZ3JvdXAKIEBlbmQgZXhhbXBs ZQogCi0gIEEgc2VsZi1ldmFsdWF0aW5nIGZvcm0geWllbGRzIGNvbnN0YW50IGNvbnNlcywg dmVjdG9ycyBhbmQgc3RyaW5ncywgYW5kIHlvdQotc2hvdWxkIG5vdCBhdHRlbXB0IHRvIG1v ZGlmeSB0aGVpciBjb250ZW50cyB2aWEgQGNvZGV7c2V0Y2FyfSwgQGNvZGV7YXNldH0gb3IK KyAgQSBzZWxmLWV2YWx1YXRpbmcgZm9ybSB5aWVsZHMgYSB2YWx1ZSB0aGF0IGJlY29tZXMg cGFydCBvZiB0aGUgcHJvZ3JhbSwKK2FuZCB5b3Ugc2hvdWxkIG5vdCB0cnkgdG8gbW9kaWZ5 IGl0IHZpYSBAY29kZXtzZXRjYXJ9LCBAY29kZXthc2V0fSBvcgogc2ltaWxhciBvcGVyYXRp b25zLiAgVGhlIExpc3AgaW50ZXJwcmV0ZXIgbWlnaHQgdW5pZnkgdGhlIGNvbnN0YW50cwog eWllbGRlZCBieSB5b3VyIHByb2dyYW0ncyBzZWxmLWV2YWx1YXRpbmcgZm9ybXMsIHNvIHRo YXQgdGhlc2UKLWNvbnN0YW50cyBtaWdodCBzaGFyZSBzdHJ1Y3R1cmUuICBAeHJlZntDb25z dGFudHMgYW5kIE11dGFiaWxpdHl9LgorY29uc3RhbnRzIG1pZ2h0IHNoYXJlIHN0cnVjdHVy ZS4gIEB4cmVme011dGFiaWxpdHl9LgogCiAgIEl0IGlzIGNvbW1vbiB0byB3cml0ZSBudW1i ZXJzLCBjaGFyYWN0ZXJzLCBzdHJpbmdzLCBhbmQgZXZlbiB2ZWN0b3JzCiBpbiBMaXNwIGNv ZGUsIHRha2luZyBhZHZhbnRhZ2Ugb2YgdGhlIGZhY3QgdGhhdCB0aGV5IHNlbGYtZXZhbHVh dGUuCkBAIC01NjQsOCArNTY0LDggQEAgUXVvdGluZwogCiBAZGVmc3BlYyBxdW90ZSBvYmpl Y3QKIFRoaXMgc3BlY2lhbCBmb3JtIHJldHVybnMgQHZhcntvYmplY3R9LCB3aXRob3V0IGV2 YWx1YXRpbmcgaXQuCi1UaGUgcmV0dXJuZWQgdmFsdWUgaXMgYSBjb25zdGFudCwgYW5kIHNo b3VsZCBub3QgYmUgbW9kaWZpZWQuCi1AeHJlZntDb25zdGFudHMgYW5kIE11dGFiaWxpdHl9 LgorVGhlIHJldHVybmVkIHZhbHVlIG1pZ2h0IGJlIHNoYXJlZCBhbmQgc2hvdWxkIG5vdCBi ZSBtb2RpZmllZC4KK0B4cmVme1NlbGYtRXZhbHVhdGluZyBGb3Jtc30uCiBAZW5kIGRlZnNw ZWMKIAogQGNpbmRleCBAc2FtcHsnfSBmb3IgcXVvdGluZwpAQCAtNjA4LDkgKzYwOCw5IEBA IFF1b3RpbmcKIAogICBBbHRob3VnaCB0aGUgZXhwcmVzc2lvbnMgQGNvZGV7KGxpc3QgJysg MSAyKX0gYW5kIEBjb2RleycoKyAxIDIpfQogYm90aCB5aWVsZCBsaXN0cyBlcXVhbCB0byBA Y29kZXsoKyAxIDIpfSwgdGhlIGZvcm1lciB5aWVsZHMgYQotZnJlc2hseS1taW50ZWQgbXV0 YWJsZSBsaXN0IHdoZXJlYXMgdGhlIGxhdHRlciB5aWVsZHMgYSBjb25zdGFudCBsaXN0Ci1i dWlsdCBmcm9tIGNvbnNlcyB0aGF0IG1heSBiZSBzaGFyZWQgd2l0aCBvdGhlciBjb25zdGFu dHMuCi1AeHJlZntDb25zdGFudHMgYW5kIE11dGFiaWxpdHl9LgorZnJlc2hseS1taW50ZWQg bXV0YWJsZSBsaXN0IHdoZXJlYXMgdGhlIGxhdHRlciB5aWVsZHMgYSBsaXN0CitidWlsdCBm cm9tIGNvbnNlcyB0aGF0IG1pZ2h0IGJlIHNoYXJlZCBhbmQgc2hvdWxkIG5vdCBiZSBtb2Rp ZmllZC4KK0B4cmVme1NlbGYtRXZhbHVhdGluZyBGb3Jtc30uCiAKICAgT3RoZXIgcXVvdGlu ZyBjb25zdHJ1Y3RzIGluY2x1ZGUgQGNvZGV7ZnVuY3Rpb259IChAcHhyZWZ7QW5vbnltb3Vz CiBGdW5jdGlvbnN9KSwgd2hpY2ggY2F1c2VzIGFuIGFub255bW91cyBsYW1iZGEgZXhwcmVz c2lvbiB3cml0dGVuIGluIExpc3AKQEAgLTcxMCw4ICs3MTAsOSBAQCBCYWNrcXVvdGUKIEBl bmQgZXhhbXBsZQogCiBJZiBhIHN1YmV4cHJlc3Npb24gb2YgYSBiYWNrcXVvdGUgY29uc3Ry dWN0IGhhcyBubyBzdWJzdGl0dXRpb25zIG9yCi1zcGxpY2VzLCBpdCBhY3RzIGxpa2UgQGNv ZGV7cXVvdGV9IGluIHRoYXQgaXQgeWllbGRzIGNvbnN0YW50IGNvbnNlcywKLXZlY3RvcnMg YW5kIHN0cmluZ3MgdGhhdCBzaG91bGQgbm90IGJlIG1vZGlmaWVkLgorc3BsaWNlcywgaXQg YWN0cyBsaWtlIEBjb2Rle3F1b3RlfSBpbiB0aGF0IGl0IHlpZWxkcyBjb25zZXMsCit2ZWN0 b3JzIGFuZCBzdHJpbmdzIHRoYXQgbWlnaHQgYmUgc2hhcmVkIGFuZCBzaG91bGQgbm90IGJl IG1vZGlmaWVkLgorQHhyZWZ7U2VsZi1FdmFsdWF0aW5nIEZvcm1zfS4KIAogQG5vZGUgRXZh bAogQHNlY3Rpb24gRXZhbApkaWZmIC0tZ2l0IGEvZG9jL2xpc3ByZWYvbGlzdHMudGV4aSBi L2RvYy9saXNwcmVmL2xpc3RzLnRleGkKaW5kZXggZmNhZjQzODZiMS4uYWU3OTNkNWUxNSAx MDA2NDQKLS0tIGEvZG9jL2xpc3ByZWYvbGlzdHMudGV4aQorKysgYi9kb2MvbGlzcHJlZi9s aXN0cy50ZXhpCkBAIC04NzMsOCArODczLDggQEAgTW9kaWZ5aW5nIExpc3RzCiBvcGVyYXRp b25zIGJlY2F1c2UgdGhleSBjaGFuZ2UgZXhpc3RpbmcgbGlzdCBzdHJ1Y3R1cmUuCiBEZXN0 cnVjdGl2ZSBvcGVyYXRpb25zIHNob3VsZCBiZSBhcHBsaWVkIG9ubHkgdG8gbXV0YWJsZSBs aXN0cywKIHRoYXQgaXMsIGxpc3RzIGNvbnN0cnVjdGVkIHZpYSBAY29kZXtjb25zfSwgQGNv ZGV7bGlzdH0gb3Igc2ltaWxhcgotb3BlcmF0aW9ucy4gIExpc3RzIGNyZWF0ZWQgYnkgcXVv dGluZyBhcmUgY29uc3RhbnRzIGFuZCBzaG91bGQgbm90IGJlCi1jaGFuZ2VkIGJ5IGRlc3Ry dWN0aXZlIG9wZXJhdGlvbnMuICBAeHJlZntDb25zdGFudHMgYW5kIE11dGFiaWxpdHl9Lgor b3BlcmF0aW9ucy4gIExpc3RzIGNyZWF0ZWQgYnkgcXVvdGluZyBhcmUgcGFydCBvZiB0aGUg cHJvZ3JhbSBhbmQKK3Nob3VsZCBub3QgYmUgY2hhbmdlZCBieSBkZXN0cnVjdGl2ZSBvcGVy YXRpb25zLiAgQHhyZWZ7TXV0YWJpbGl0eX0uCiAKIEBjaW5kZXggQ0wgbm90ZS0tLUBjb2Rl e3JwbGFjYX0gdnMgQGNvZGV7c2V0Y2FyfQogQHF1b3RhdGlvbgpAQCAtOTExLDcgKzkxMSw3 IEBAIFNldGNhcgogCiBAZXhhbXBsZQogQGdyb3VwCi0oc2V0cSB4IChsaXN0IDEgMikpICA7 IEBye0NyZWF0ZSBhIG11dGFibGUgbGlzdC59Cisoc2V0cSB4IChsaXN0IDEgMikpCiAgICAg IEByZXN1bHR7fSAoMSAyKQogQGVuZCBncm91cAogQGdyb3VwCkBAIC05MzEsNyArOTMxLDcg QEAgU2V0Y2FyCiAKIEBleGFtcGxlCiBAZ3JvdXAKLTs7IEBye0NyZWF0ZSB0d28gbXV0YWJs ZSBsaXN0cyB0aGF0IGFyZSBwYXJ0bHkgc2hhcmVkLn0KKzs7IEBye0NyZWF0ZSB0d28gbGlz dHMgdGhhdCBhcmUgcGFydGx5IHNoYXJlZC59CiAoc2V0cSB4MSAobGlzdCAnYSAnYiAnYykp CiAgICAgIEByZXN1bHR7fSAoYSBiIGMpCiAoc2V0cSB4MiAoY29ucyAneiAoY2RyIHgxKSkp CkBAIC0xMDIyLDExICsxMDIyLDExIEBAIFNldGNkcgogCiBAZXhhbXBsZQogQGdyb3VwCi0o c2V0cSB4IChsaXN0IDEgMiAzKSkgIDsgQHJ7Q3JlYXRlIGEgbXV0YWJsZSBsaXN0Ln0KKyhz ZXRxIHggKGxpc3QgMSAyIDMpKQogICAgICBAcmVzdWx0e30gKDEgMiAzKQogQGVuZCBncm91 cAogQGdyb3VwCi0oc2V0Y2RyIHggJyg0KSkgIDsgQHJ7TW9kaWZ5IHRoZSBsaXN0J3MgdGFp bCB0byBiZSBhIGNvbnN0YW50IGxpc3QufQorKHNldGNkciB4ICcoNCkpCiAgICAgIEByZXN1 bHR7fSAoNCkKIEBlbmQgZ3JvdXAKIEBncm91cApAQCAtMTEzNSwxMSArMTEzNSwxMSBAQCBS ZWFycmFuZ2VtZW50CiAKIEBleGFtcGxlCiBAZ3JvdXAKLShzZXRxIHggKGxpc3QgMSAyIDMp KSAgOyBAcntDcmVhdGUgYSBtdXRhYmxlIGxpc3QufQorKHNldHEgeCAobGlzdCAxIDIgMykp CiAgICAgIEByZXN1bHR7fSAoMSAyIDMpCiBAZW5kIGdyb3VwCiBAZ3JvdXAKLShuY29uYyB4 ICcoNCA1KSkgIDsgQHJ7TW9kaWZ5IHRoZSBsaXN0J3MgdGFpbCB0byBiZSBhIGNvbnN0YW50 IGxpc3QufQorKG5jb25jIHggJyg0IDUpKQogICAgICBAcmVzdWx0e30gKDEgMiAzIDQgNSkK IEBlbmQgZ3JvdXAKIEBncm91cApkaWZmIC0tZ2l0IGEvZG9jL2xpc3ByZWYvb2JqZWN0cy50 ZXhpIGIvZG9jL2xpc3ByZWYvb2JqZWN0cy50ZXhpCmluZGV4IDFkNWIyYzY5MGYuLmEwYWZh ZGMyZDcgMTAwNjQ0Ci0tLSBhL2RvYy9saXNwcmVmL29iamVjdHMudGV4aQorKysgYi9kb2Mv bGlzcHJlZi9vYmplY3RzLnRleGkKQEAgLTQ2LDEwICs0Niw2IEBAIExpc3AgRGF0YSBUeXBl cwogTGlzcCB2YXJpYWJsZXMgY2FuIG9ubHkgdGFrZSBvbiB2YWx1ZXMgb2YgYSBjZXJ0YWlu IHR5cGUuCiBAeHJlZntWYXJpYWJsZXMgd2l0aCBSZXN0cmljdGVkIFZhbHVlc30uKQogCi0g IFNvbWUgTGlzcCBvYmplY3RzIGFyZSBAZGZue2NvbnN0YW50fTogdGhlaXIgdmFsdWVzIHNo b3VsZCBuZXZlciBjaGFuZ2UuCi1PdGhlcnMgYXJlIEBkZm57bXV0YWJsZX06IHRoZWlyIHZh bHVlcyBjYW4gYmUgY2hhbmdlZCB2aWEgZGVzdHJ1Y3RpdmUKLW9wZXJhdGlvbnMgdGhhdCBp bnZvbHZlIHNpZGUgZWZmZWN0cy4KLQogICBUaGlzIGNoYXB0ZXIgZGVzY3JpYmVzIHRoZSBw dXJwb3NlLCBwcmludGVkIHJlcHJlc2VudGF0aW9uLCBhbmQgcmVhZAogc3ludGF4IG9mIGVh Y2ggb2YgdGhlIHN0YW5kYXJkIHR5cGVzIGluIEdOVSBFbWFjcyBMaXNwLiAgRGV0YWlscyBv biBob3cKIHRvIHVzZSB0aGVzZSB0eXBlcyBjYW4gYmUgZm91bmQgaW4gbGF0ZXIgY2hhcHRl cnMuCkBAIC02Myw3ICs1OSw3IEBAIExpc3AgRGF0YSBUeXBlcwogKiBDaXJjdWxhciBPYmpl Y3RzOjogICAgICAgICAgICBSZWFkIHN5bnRheCBmb3IgY2lyY3VsYXIgc3RydWN0dXJlLgog KiBUeXBlIFByZWRpY2F0ZXM6OiAgICAgICAgICAgICBUZXN0cyByZWxhdGVkIHRvIHR5cGVz LgogKiBFcXVhbGl0eSBQcmVkaWNhdGVzOjogICAgICAgICBUZXN0cyBvZiBlcXVhbGl0eSBi ZXR3ZWVuIGFueSB0d28gb2JqZWN0cy4KLSogQ29uc3RhbnRzIGFuZCBNdXRhYmlsaXR5Ojog ICAgV2hldGhlciBhbiBvYmplY3QncyB2YWx1ZSBjYW4gY2hhbmdlLgorKiBNdXRhYmlsaXR5 OjogICAgICAgICAgICAgICAgICBTb21lIG9iamVjdHMgc2hvdWxkIG5vdCBiZSBtb2RpZmll ZC4KIEBlbmQgbWVudQogCiBAbm9kZSBQcmludGVkIFJlcHJlc2VudGF0aW9uCkBAIC0yMzc5 LDUxICsyMzc1LDQ4IEBAIEVxdWFsaXR5IFByZWRpY2F0ZXMKIEBlbmQgZXhhbXBsZQogQGVu ZCBkZWZ1bgogCi1Abm9kZSBDb25zdGFudHMgYW5kIE11dGFiaWxpdHkKLUBzZWN0aW9uIENv bnN0YW50cyBhbmQgTXV0YWJpbGl0eQotQGNpbmRleCBjb25zdGFudHMKK0Bub2RlIE11dGFi aWxpdHkKK0BzZWN0aW9uIE11dGFiaWxpdHkKIEBjaW5kZXggbXV0YWJsZSBvYmplY3RzCiAK LSAgU29tZSBMaXNwIG9iamVjdHMgYXJlIGNvbnN0YW50OiB0aGVpciB2YWx1ZXMgc2hvdWxk IG5ldmVyIGNoYW5nZQotZHVyaW5nIGEgc2luZ2xlIGV4ZWN1dGlvbiBvZiBFbWFjcyBydW5u aW5nIHdlbGwtYmVoYXZlZCBMaXNwIGNvZGUuCi1Gb3IgZXhhbXBsZSwgeW91IGNhbiBjcmVh dGUgYSBuZXcgaW50ZWdlciBieSBjYWxjdWxhdGluZyBvbmUsIGJ1dCB5b3UKLWNhbm5vdCBt b2RpZnkgdGhlIHZhbHVlIG9mIGFuIGV4aXN0aW5nIGludGVnZXIuCisgIFNvbWUgTGlzcCBv YmplY3RzIHNob3VsZCBuZXZlciBjaGFuZ2UuICBGb3IgZXhhbXBsZSwgeW91IGNhbiBjcmVh dGUKK2EgbmV3IG51bWJlciBieSBjYWxjdWxhdGluZyBvbmUsIGJ1dCB5b3UgY2Fubm90IG1v ZGlmeSB0aGUgdmFsdWUgb2YgYW4KK2V4aXN0aW5nIG51bWJlci4KIAotICBPdGhlciBMaXNw IG9iamVjdHMgYXJlIG11dGFibGU6IGl0IGlzIHNhZmUgdG8gY2hhbmdlIHRoZWlyIHZhbHVl cwotdmlhIGRlc3RydWN0aXZlIG9wZXJhdGlvbnMgaW52b2x2aW5nIHNpZGUgZWZmZWN0cy4g IEZvciBleGFtcGxlLCBhbgotZXhpc3RpbmcgbWFya2VyIGNhbiBiZSBjaGFuZ2VkIGJ5IG1v dmluZyB0aGUgbWFya2VyIHRvIHBvaW50IHRvCi1zb21ld2hlcmUgZWxzZS4KKyAgT3RoZXIg TGlzcCBvYmplY3RzIGFyZSBAZGZue211dGFibGV9OiBpdCBpcyBzYWZlIHRvIGNoYW5nZSB0 aGVpcgordmFsdWVzIHZpYSBkZXN0cnVjdGl2ZSBvcGVyYXRpb25zIGludm9sdmluZyBzaWRl IGVmZmVjdHMuICBGb3IKK2V4YW1wbGUsIGFuIGV4aXN0aW5nIG1hcmtlciBjYW4gYmUgY2hh bmdlZCBieSBtb3ZpbmcgdGhlIG1hcmtlciB0bworcG9pbnQgdG8gc29tZXdoZXJlIGVsc2Uu CiAKLSAgQWx0aG91Z2ggYWxsIG51bWJlcnMgYXJlIGNvbnN0YW50cyBhbmQgYWxsIG1hcmtl cnMgYXJlCi1tdXRhYmxlLCBzb21lIHR5cGVzIGNvbnRhaW4gYm90aCBjb25zdGFudCBhbmQg bXV0YWJsZSBtZW1iZXJzLiAgVGhlc2UKKyAgQWx0aG91Z2ggbnVtYmVycyBuZXZlciBjaGFu Z2UgYW5kIGFsbCBtYXJrZXJzIGFyZSBtdXRhYmxlLCBhIHR5cGUKK2NhbiBiZSBhIGh5YnJp ZCB3aXRoIHNvbWUgbWVtYmVycyBtdXRhYmxlIGFuZCBvdGhlciBtZW1iZXJzIG5vdC4gIFRo ZXNlCiB0eXBlcyBpbmNsdWRlIGNvbnNlcywgdmVjdG9ycywgc3RyaW5ncywgYW5kIHN5bWJv bHMuICBGb3IgZXhhbXBsZSwgdGhlIHN0cmluZwotbGl0ZXJhbCBAY29kZXsiYWFhIn0geWll bGRzIGEgY29uc3RhbnQgc3RyaW5nLCB3aGVyZWFzIHRoZSBmdW5jdGlvbgorbGl0ZXJhbCBA Y29kZXsiYWFhIn0geWllbGRzIGEgc3RyaW5nIHRoYXQgc2hvdWxkIG5vdCBiZSBjaGFuZ2Vk LCB3aGVyZWFzIHRoZQogY2FsbCBAY29kZXsobWFrZS1zdHJpbmcgMyA/YSl9IHlpZWxkcyBh IG11dGFibGUgc3RyaW5nIHRoYXQgY2FuIGJlCiBjaGFuZ2VkIHZpYSBsYXRlciBjYWxscyB0 byBAY29kZXthc2V0fS4KIAotICBBIG11dGFibGUgb2JqZWN0IGNhbiBiZWNvbWUgY29uc3Rh bnQgaWYgaXQgaXMgcGFydCBvZiBhbiBleHByZXNzaW9uCi10aGF0IGlzIGV2YWx1YXRlZC4g IFRoZSByZXZlcnNlIGRvZXMgbm90IG9jY3VyOiBjb25zdGFudCBvYmplY3RzCi1zaG91bGQg c3RheSBjb25zdGFudC4KKyAgQSBtdXRhYmxlIG9iamVjdCBzdG9wcyBiZWluZyBtdXRhYmxl IGlmIGl0IGlzIHBhcnQgb2YgYW4gZXhwcmVzc2lvbgordGhhdCBpcyBldmFsdWF0ZWQuICBG b3IgZXhhbXBsZSwgaW4gQGNvZGV7KGV2YWwgKGxpc3QgJ3F1b3RlIChsaXN0IDEpKSl9Cit0 aGUgbGlzdCBAY29kZXsoMSl9IHdhcyBtdXRhYmxlIHdoZW4gaXQgd2FzIGNyZWF0ZWQsIGJ1 dCBpdCBzaG91bGQgbm90CitiZSBjaGFuZ2VkIGFmdGVyIGl0IHdhcyBwYXJ0IG9mIGFuIGFy Z3VtZW50IHRvIEBjb2Rle2V2YWx9LiAgVGhlCityZXZlcnNlIGRvZXMgbm90IG9jY3VyOiBh biBvYmplY3QgdGhhdCBzaG91bGQgbm90IGJlIGNoYW5nZWQgbmV2ZXIKK2JlY29tZXMgbXV0 YWJsZSBhZnRlcndhcmRzLgogCiAgIFRyeWluZyB0byBtb2RpZnkgYSBjb25zdGFudCB2YXJp YWJsZSBzaWduYWxzIGFuIGVycm9yCiAoQHB4cmVme0NvbnN0YW50IFZhcmlhYmxlc30pLgot QSBwcm9ncmFtIHNob3VsZCBub3QgYXR0ZW1wdCB0byBtb2RpZnkgb3RoZXIgdHlwZXMgb2Yg Y29uc3RhbnRzIGJlY2F1c2UgdGhlCi1yZXN1bHRpbmcgYmVoYXZpb3IgaXMgdW5kZWZpbmVk OiB0aGUgTGlzcCBpbnRlcnByZXRlciBtaWdodCBvciBtaWdodAotbm90IGRldGVjdCB0aGUg ZXJyb3IsIGFuZCBpZiBpdCBkb2VzIG5vdCBkZXRlY3QgdGhlIGVycm9yIHRoZQotaW50ZXJw cmV0ZXIgY2FuIGJlaGF2ZSB1bnByZWRpY3RhYmx5IHRoZXJlYWZ0ZXIuICBBbm90aGVyIHdh eSB0byBwdXQKLXRoaXMgaXMgdGhhdCBhbHRob3VnaCBtdXRhYmxlIG9iamVjdHMgYXJlIHNh ZmUgdG8gY2hhbmdlIGFuZCBjb25zdGFudAotdmFyaWFibGVzIHJlbGlhYmx5IHByZXZlbnQg YXR0ZW1wdHMgdG8gY2hhbmdlIHRoZW0sIG90aGVyIGNvbnN0YW50cwotYXJlIG5vdCBzYWZl bHkgbXV0YWJsZTogaWYgYSBtaXNiZWhhdmluZyBwcm9ncmFtIHRyaWVzIHRvIGNoYW5nZSBz dWNoIGEKLWNvbnN0YW50IHRoZW4gdGhlIGNvbnN0YW50J3MgdmFsdWUgbWlnaHQgYWN0dWFs bHkgY2hhbmdlLCBvciB0aGUKLXByb2dyYW0gbWlnaHQgY3Jhc2ggb3Igd29yc2UuICBUaGlz IHByb2JsZW0gb2NjdXJzCi13aXRoIHR5cGVzIHRoYXQgaGF2ZSBib3RoIGNvbnN0YW50IGFu ZCBtdXRhYmxlIG1lbWJlcnMsIGFuZCB0aGF0IGhhdmUKLW11dGF0b3JzIGxpa2UgQGNvZGV7 c2V0Y2FyfSBhbmQgQGNvZGV7YXNldH0gdGhhdCBhcmUgdmFsaWQgb24gbXV0YWJsZQotb2Jq ZWN0cyBidXQgaGF6YXJkb3VzIG9uIGNvbnN0YW50cy4KLQotICBXaGVuIHRoZSBzYW1lIGNv bnN0YW50IG9jY3VycyBtdWx0aXBsZSB0aW1lcyBpbiBhIHByb2dyYW0sIHRoZSBMaXNwCi1p bnRlcnByZXRlciBtaWdodCBzYXZlIHRpbWUgb3Igc3BhY2UgYnkgcmV1c2luZyBleGlzdGlu ZyBjb25zdGFudHMgb3IKLWNvbnN0YW50IGNvbXBvbmVudHMuICBGb3IgZXhhbXBsZSwgQGNv ZGV7KGVxICJhYmMiICJhYmMiKX0gcmV0dXJucworSWYgYSBwcm9ncmFtIGF0dGVtcHRzIHRv IGNoYW5nZSBvdGhlciBvYmplY3RzIHRoYXQgc2hvdWxkIG5vdCBiZQorY2hhbmdlZCwgdGhl IHJlc3VsdGluZyBiZWhhdmlvciBpcyB1bmRlZmluZWQ6IHRoZSBMaXNwIGludGVycHJldGVy CittaWdodCBzaWduYWwgYW4gZXJyb3IsIG9yIGl0IG1pZ2h0IGNyYXNoIG9yIGJlaGF2ZSB1 bnByZWRpY3RhYmx5IGluCitvdGhlciB3YXlzLkBmb290bm90ZXtUaGlzIGlzIHRoZSBiZWhh dmlvciBzcGVjaWZpZWQgZm9yIGxhbmd1YWdlcyBsaWtlCitDb21tb24gTGlzcCBhbmQgQywg YW5kIGl0IGRpZmZlcnMgZnJvbSB0aGUgYmVoYXZpb3Igb2YgbGFuZ3VhZ2VzIGxpa2UKK0ph dmFTY3JpcHQgYW5kIFB5dGhvbiB3aGVyZSBhbiBpbnRlcnByZXRlciBpcyByZXF1aXJlZCB0 byBzaWduYWwgYW4KK2Vycm9yIGlmIGEgcHJvZ3JhbSBhdHRlbXB0cyB0byBjaGFuZ2UgYSBj b25zdGFudC4gIElkZWFsbHkgdGhlIEVtYWNzCitMaXNwIGludGVycHJldGVyIHdpbGwgZXZv bHZlIGluIGxhdHRlciBkaXJlY3Rpb24ufQorCisgIFdoZW4gdGhlIHNhbWUgdmFsdWUgYXBw ZWFycyBtdWx0aXBsZSB0aW1lcyBpbiBhIHByb2dyYW0sIHRoZSBMaXNwCitpbnRlcnByZXRl ciBtaWdodCBzYXZlIHRpbWUgb3Igc3BhY2UgYnkgcmV1c2luZyBleGlzdGluZyB2YWx1ZXMg b3IKK3RoZWlyIGNvbXBvbmVudHMuICBGb3IgZXhhbXBsZSwgQGNvZGV7KGVxICJhYmMiICJh YmMiKX0gcmV0dXJucwogQGNvZGV7dH0gaWYgdGhlIGludGVycHJldGVyIGNyZWF0ZXMgb25s eSBvbmUgaW5zdGFuY2Ugb2YgdGhlIHN0cmluZwotY29uc3RhbnQgQGNvZGV7ImFiYyJ9LCBh bmQgcmV0dXJucyBAY29kZXtuaWx9IGlmIGl0IGNyZWF0ZXMgdHdvCitsaXRlcmFsIEBjb2Rl eyJhYmMifSwgYW5kIHJldHVybnMgQGNvZGV7bmlsfSBpZiBpdCBjcmVhdGVzIHR3bwogaW5z dGFuY2VzLiAgTGlzcCBwcm9ncmFtcyBzaG91bGQgYmUgd3JpdHRlbiBzbyB0aGF0IHRoZXkg d29yawogcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoaXMgb3B0aW1pemF0aW9uIGlzIGluIHVz ZS4KZGlmZiAtLWdpdCBhL2RvYy9saXNwcmVmL3NlcXVlbmNlcy50ZXhpIGIvZG9jL2xpc3By ZWYvc2VxdWVuY2VzLnRleGkKaW5kZXggMWNiMGQwNWNjNy4uOTFjMzA0OWY4NyAxMDA2NDQK LS0tIGEvZG9jL2xpc3ByZWYvc2VxdWVuY2VzLnRleGkKKysrIGIvZG9jL2xpc3ByZWYvc2Vx dWVuY2VzLnRleGkKQEAgLTE4MywxMSArMTgzLDExIEBAIFNlcXVlbmNlIEZ1bmN0aW9ucwog CiBAZXhhbXBsZQogQGdyb3VwCi0oc2V0cSBiYXIgKGxpc3QgMSAyKSkgIDsgQHJ7Q3JlYXRl IGEgbXV0YWJsZSBsaXN0Ln0KKyhzZXRxIGJhciAobGlzdCAxIDIpKQogICAgICBAcmVzdWx0 e30gKDEgMikKIEBlbmQgZ3JvdXAKIEBncm91cAotKHNldHEgeCAodmVjdG9yICdmb28gYmFy KSkgIDsgQHJ7Q3JlYXRlIGEgbXV0YWJsZSB2ZWN0b3IufQorKHNldHEgeCAodmVjdG9yICdm b28gYmFyKSkKICAgICAgQHJlc3VsdHt9IFtmb28gKDEgMildCiBAZW5kIGdyb3VwCiBAZ3Jv dXAKQEAgLTI3OCw3ICsyNzgsNyBAQCBTZXF1ZW5jZSBGdW5jdGlvbnMKIAogQGV4YW1wbGUK IEBncm91cAotKHNldHEgeCAobGlzdCAnYSAnYiAnYykpICA7IEBye0NyZWF0ZSBhIG11dGFi bGUgbGlzdC59Cisoc2V0cSB4IChsaXN0ICdhICdiICdjKSkKICAgICAgQHJlc3VsdHt9IChh IGIgYykKIEBlbmQgZ3JvdXAKIEBncm91cApAQCAtMzIwLDcgKzMyMCw3IEBAIFNlcXVlbmNl IEZ1bmN0aW9ucwogICBGb3IgdGhlIHZlY3RvciwgaXQgaXMgZXZlbiBzaW1wbGVyIGJlY2F1 c2UgeW91IGRvbid0IG5lZWQgc2V0cToKIAogQGV4YW1wbGUKLShzZXRxIHggKGNvcHktc2Vx dWVuY2UgWzEgMiAzIDRdKSkgIDsgQHJ7Q3JlYXRlIGEgbXV0YWJsZSB2ZWN0b3IufQorKHNl dHEgeCAoY29weS1zZXF1ZW5jZSBbMSAyIDMgNF0pKQogICAgICBAcmVzdWx0e30gWzEgMiAz IDRdCiAobnJldmVyc2UgeCkKICAgICAgQHJlc3VsdHt9IFs0IDMgMiAxXQpAQCAtMzMxLDYg KzMzMSw3IEBAIFNlcXVlbmNlIEZ1bmN0aW9ucwogTm90ZSB0aGF0IHVubGlrZSBAY29kZXty ZXZlcnNlfSwgdGhpcyBmdW5jdGlvbiBkb2Vzbid0IHdvcmsgd2l0aCBzdHJpbmdzLgogQWx0 aG91Z2ggeW91IGNhbiBhbHRlciBzdHJpbmcgZGF0YSBieSB1c2luZyBAY29kZXthc2V0fSwg aXQgaXMgc3Ryb25nbHkKIGVuY291cmFnZWQgdG8gdHJlYXQgc3RyaW5ncyBhcyBpbW11dGFi bGUgZXZlbiB3aGVuIHRoZXkgYXJlIG11dGFibGUuCitAeHJlZntNdXRhYmlsaXR5fS4KIAog QGVuZCBkZWZ1bgogCkBAIC0zNzQsNyArMzc1LDcgQEAgU2VxdWVuY2UgRnVuY3Rpb25zCiAK IEBleGFtcGxlCiBAZ3JvdXAKLShzZXRxIG51bXMgKGxpc3QgMSAzIDIgNiA1IDQgMCkpICA7 IEBye0NyZWF0ZSBhIG11dGFibGUgbGlzdC59Cisoc2V0cSBudW1zIChsaXN0IDEgMyAyIDYg NSA0IDApKQogICAgICBAcmVzdWx0e30gKDEgMyAyIDYgNSA0IDApCiBAZW5kIGdyb3VwCiBA Z3JvdXAKQEAgLTEyMjgsNyArMTIyOSw3IEBAIEFycmF5IEZ1bmN0aW9ucwogCiBAZXhhbXBs ZQogQGdyb3VwCi0oc2V0cSB3ICh2ZWN0b3IgJ2ZvbyAnYmFyICdiYXopKSAgOyBAcntDcmVh dGUgYSBtdXRhYmxlIHZlY3Rvci59Cisoc2V0cSB3ICh2ZWN0b3IgJ2ZvbyAnYmFyICdiYXop KQogICAgICBAcmVzdWx0e30gW2ZvbyBiYXIgYmF6XQogKGFzZXQgdyAwICdmdSkKICAgICAg QHJlc3VsdHt9IGZ1CkBAIC0xMjM3LDcgKzEyMzgsNyBAQCBBcnJheSBGdW5jdGlvbnMKIEBl bmQgZ3JvdXAKIAogQGdyb3VwCi07OyBAcntAY29kZXtjb3B5LXNlcXVlbmNlfSBjcmVhdGVz IGEgbXV0YWJsZSBzdHJpbmcufQorOzsgQHJ7QGNvZGV7Y29weS1zZXF1ZW5jZX0gY29waWVz IHRoZSBzdHJpbmcgdG8gYmUgbW9kaWZpZWQgbGF0ZXIufQogKHNldHEgeCAoY29weS1zZXF1 ZW5jZSAiYXNkZmFzZmQiKSkKICAgICAgQHJlc3VsdHt9ICJhc2RmYXNmZCIKIChhc2V0IHgg MyA/WikKQEAgLTEyNDcsOSArMTI0OCw3IEBAIEFycmF5IEZ1bmN0aW9ucwogQGVuZCBncm91 cAogQGVuZCBleGFtcGxlCiAKLVRoZSBAdmFye2FycmF5fSBzaG91bGQgYmUgbXV0YWJsZTsg dGhhdCBpcywgaXQgc2hvdWxkIG5vdCBiZSBhIGNvbnN0YW50LAotc3VjaCBhcyB0aGUgY29u c3RhbnRzIGNyZWF0ZWQgdmlhIHF1b3Rpbmcgb3IgdmlhIHNlbGYtZXZhbHVhdGluZyBmb3Jt cy4KLUB4cmVme0NvbnN0YW50cyBhbmQgTXV0YWJpbGl0eX0uCitUaGUgQHZhcnthcnJheX0g c2hvdWxkIGJlIG11dGFibGUuICBAeHJlZntNdXRhYmlsaXR5fS4KIAogSWYgQHZhcnthcnJh eX0gaXMgYSBzdHJpbmcgYW5kIEB2YXJ7b2JqZWN0fSBpcyBub3QgYSBjaGFyYWN0ZXIsIGEK IEBjb2Rle3dyb25nLXR5cGUtYXJndW1lbnR9IGVycm9yIHJlc3VsdHMuICBUaGUgZnVuY3Rp b24gY29udmVydHMgYQpAQCAtMTI2Miw3ICsxMjYxLDYgQEAgQXJyYXkgRnVuY3Rpb25zCiAK IEBleGFtcGxlCiBAZ3JvdXAKLTs7IEBye0NyZWF0ZSBhIG11dGFibGUgdmVjdG9yIGFuZCB0 aGVuIGZpbGwgaXQgd2l0aCB6ZXJvcy59CiAoc2V0cSBhIChjb3B5LXNlcXVlbmNlIFthIGIg YyBkIGUgZiBnXSkpCiAgICAgIEByZXN1bHR7fSBbYSBiIGMgZCBlIGYgZ10KIChmaWxsYXJy YXkgYSAwKQpAQCAtMTI3MSw3ICsxMjY5LDYgQEAgQXJyYXkgRnVuY3Rpb25zCiAgICAgIEBy ZXN1bHR7fSBbMCAwIDAgMCAwIDAgMF0KIEBlbmQgZ3JvdXAKIEBncm91cAotOzsgQHJ7Q3Jl YXRlIGEgbXV0YWJsZSBzdHJpbmcgYW5kIHRoZW4gZmlsbCBpdCB3aXRoICItIi59CiAoc2V0 cSBzIChjb3B5LXNlcXVlbmNlICJXaGVuIGluIHRoZSBjb3Vyc2UiKSkKICAgICAgQHJlc3Vs dHt9ICJXaGVuIGluIHRoZSBjb3Vyc2UiCiAoZmlsbGFycmF5IHMgPy0pCkBAIC0xMzEwLDgg KzEzMDcsOCBAQCBWZWN0b3JzCiBldmFsdWF0aW9uOiB0aGUgcmVzdWx0IG9mIGV2YWx1YXRp bmcgaXQgaXMgdGhlIHNhbWUgdmVjdG9yLiAgVGhpcyBkb2VzCiBub3QgZXZhbHVhdGUgb3Ig ZXZlbiBleGFtaW5lIHRoZSBlbGVtZW50cyBvZiB0aGUgdmVjdG9yLgogQHhyZWZ7U2VsZi1F dmFsdWF0aW5nIEZvcm1zfS4gIFZlY3RvcnMgd3JpdHRlbiB3aXRoIHNxdWFyZSBicmFja2V0 cwotYXJlIGNvbnN0YW50cyBhbmQgc2hvdWxkIG5vdCBiZSBtb2RpZmllZCB2aWEgQGNvZGV7 YXNldH0gb3Igb3RoZXIKLWRlc3RydWN0aXZlIG9wZXJhdGlvbnMuICBAeHJlZntDb25zdGFu dHMgYW5kIE11dGFiaWxpdHl9Lgorc2hvdWxkIG5vdCBiZSBtb2RpZmllZCB2aWEgQGNvZGV7 YXNldH0gb3Igb3RoZXIgZGVzdHJ1Y3RpdmUKK29wZXJhdGlvbnMuICBAeHJlZntNdXRhYmls aXR5fS4KIAogICBIZXJlIGFyZSBleGFtcGxlcyBpbGx1c3RyYXRpbmcgdGhlc2UgcHJpbmNp cGxlczoKIApkaWZmIC0tZ2l0IGEvZG9jL2xpc3ByZWYvc3RyaW5ncy50ZXhpIGIvZG9jL2xp c3ByZWYvc3RyaW5ncy50ZXhpCmluZGV4IGE0YzljMjU0OWMuLjcwYzNiM2NmNGIgMTAwNjQ0 Ci0tLSBhL2RvYy9saXNwcmVmL3N0cmluZ3MudGV4aQorKysgYi9kb2MvbGlzcHJlZi9zdHJp bmdzLnRleGkKQEAgLTQ5LDEwICs0OSw5IEBAIFN0cmluZyBCYXNpY3MKIAogICBTaW5jZSBz dHJpbmdzIGFyZSBhcnJheXMsIGFuZCB0aGVyZWZvcmUgc2VxdWVuY2VzIGFzIHdlbGwsIHlv dSBjYW4KIG9wZXJhdGUgb24gdGhlbSB3aXRoIHRoZSBnZW5lcmFsIGFycmF5IGFuZCBzZXF1 ZW5jZSBmdW5jdGlvbnMgZG9jdW1lbnRlZAotaW4gQHJlZntTZXF1ZW5jZXMgQXJyYXlzIFZl Y3RvcnN9LiAgRm9yIGV4YW1wbGUsIHlvdSBjYW4gYWNjZXNzIG9yCi1jaGFuZ2UgaW5kaXZp ZHVhbCBjaGFyYWN0ZXJzIGluIGEgc3RyaW5nIHVzaW5nIHRoZSBmdW5jdGlvbnMgQGNvZGV7 YXJlZn0KLWFuZCBAY29kZXthc2V0fSAoQHB4cmVme0FycmF5IEZ1bmN0aW9uc30pLiAgSG93 ZXZlciwgeW91IHNob3VsZCBub3QKLXRyeSB0byBjaGFuZ2UgdGhlIGNvbnRlbnRzIG9mIGNv bnN0YW50IHN0cmluZ3MgKEBweHJlZntNb2RpZnlpbmcgU3RyaW5nc30pLgoraW4gQHJlZntT ZXF1ZW5jZXMgQXJyYXlzIFZlY3RvcnN9LiAgRm9yIGV4YW1wbGUsIHlvdSBjYW4gYWNjZXNz CitpbmRpdmlkdWFsIGNoYXJhY3RlcnMgaW4gYSBzdHJpbmcgdXNpbmcgdGhlIGZ1bmN0aW9u IEBjb2Rle2FyZWZ9CisoQHB4cmVme0FycmF5IEZ1bmN0aW9uc30pLgogCiAgIFRoZXJlIGFy ZSB0d28gdGV4dCByZXByZXNlbnRhdGlvbnMgZm9yIG5vbi1AYWNyb255bXtBU0NJSX0KIGNo YXJhY3RlcnMgaW4gRW1hY3Mgc3RyaW5ncyAoYW5kIGluIGJ1ZmZlcnMpOiB1bmlieXRlIGFu ZCBtdWx0aWJ5dGUuCkBAIC0zODIsOSArMzgxLDcgQEAgTW9kaWZ5aW5nIFN0cmluZ3MKIEBj aW5kZXggc3RyaW5nIG1vZGlmaWNhdGlvbgogCiAgIFlvdSBjYW4gYWx0ZXIgdGhlIGNvbnRl bnRzIG9mIGEgbXV0YWJsZSBzdHJpbmcgdmlhIG9wZXJhdGlvbnMKLWRlc2NyaWJlZCBpbiB0 aGlzIHNlY3Rpb24uICBIb3dldmVyLCB5b3Ugc2hvdWxkIG5vdCB0cnkgdG8gdXNlIHRoZXNl Ci1vcGVyYXRpb25zIHRvIGFsdGVyIHRoZSBjb250ZW50cyBvZiBhIGNvbnN0YW50IHN0cmlu Zy4KLUB4cmVme0NvbnN0YW50cyBhbmQgTXV0YWJpbGl0eX0uCitkZXNjcmliZWQgaW4gdGhp cyBzZWN0aW9uLiAgQHhyZWZ7TXV0YWJpbGl0eX0uCiAKICAgVGhlIG1vc3QgYmFzaWMgd2F5 IHRvIGFsdGVyIHRoZSBjb250ZW50cyBvZiBhbiBleGlzdGluZyBzdHJpbmcgaXMgd2l0aAog QGNvZGV7YXNldH0gKEBweHJlZntBcnJheSBGdW5jdGlvbnN9KS4gIEBjb2Rleyhhc2V0IEB2 YXJ7c3RyaW5nfQotLSAKMi4xNy4xCgo= --------------47B5244C8E6A6AEFF8FB82B3-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 May 2020 03:14: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, Richard Stallman , Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158908041110271 (code B ref 40671); Sun, 10 May 2020 03:14:02 +0000 Received: (at 40671) by debbugs.gnu.org; 10 May 2020 03:13:31 +0000 Received: from localhost ([127.0.0.1]:48771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXcPD-0002fb-8t for submit@debbugs.gnu.org; Sat, 09 May 2020 23:13:31 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:37700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXcPB-0002fN-4y for 40671@debbugs.gnu.org; Sat, 09 May 2020 23:13:30 -0400 Received: by mail-wr1-f45.google.com with SMTP id k1so6549060wrx.4 for <40671@debbugs.gnu.org>; Sat, 09 May 2020 20:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/sUS3ufzVZxPnFo4W84QBRZm0QdOWM3EYxR/J0pxhXE=; b=rSjdtBCtcXo1BLRdys2oIGsd6/+QELIyggPqYzsOkoMcuexAdi+QDHsRZ+lBe4pBtp 0eSQoziUJR8DLHE742ClTMUAsIIPPxd4CKR7WIyYajfNURXsBdEKUnbin5vRtTnLrdke exYGpCK5UtQ27otciVLnm+0dsvT3W8Pip0gm35gGkzbjMKNdfE/vOFJChVS7OOzc28rH v9cwaJQnn0tCMAGlw9Z2qe68EhBlM8BMo9Ro2f+3e3nXqfSome7ohaN4F897WhBmbGmC LMjgvB2GV/mCTldJ1vOUxdAt8532bZ5CCGXGQcl5duAnuYtiVuMtaZyqnSsuLTyM2yuF XT5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/sUS3ufzVZxPnFo4W84QBRZm0QdOWM3EYxR/J0pxhXE=; b=jB8vWc3gG/rJ0wED9/OzlSnM0xfMEdgPf++Vple3aOm23rdoOgQziJxSvNFpSRkmLu 66ACt/m8sQjnSnAEeZCPWejGZi4DGovVPtymTNU7r36orGmaAYZq8r3rgvJ2maTBt8bw XpXHXZyFooayJTyImTfW9Ve5x3296G+i8n5Nwwtjmdy8aQ9d6duwRSxUeigK5rbYe5Im wmP4jHwnfhmGn3LRo85wXTUR1GO7WvSbq8B9+dTkKdWRFAoZ+beYnezzZkZ0ESx9CcIc kVfPmcdvcny+M478k+zFbtj/HqaEsLR0kC8qJG41X5T/h+T3wkN4P6AW20tJ3GGW4+xf iDRg== X-Gm-Message-State: AGi0PuauKMtQcvhaDQT+zRVBN9HgUWjX3k5e+PhjgcOvv3T4EtNMfy9Z 2KU/1vAhcBqax0jPcWMK7RI= X-Google-Smtp-Source: APiQypKNepNaCUXSaOK3G7hLUW+/8VgL6fDTEaWH7qSC5EWnkVoL2HarbJftgfPipAkKKV+vhY4Ayg== X-Received: by 2002:a05:6000:1106:: with SMTP id z6mr4623548wrw.336.1589080403233; Sat, 09 May 2020 20:13:23 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id d133sm22650971wmc.27.2020.05.09.20.13.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 20:13:22 -0700 (PDT) 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> From: Dmitry Gutov Message-ID: <88af48c6-bc39-6ab0-59ec-7d537f2d375d@yandex.ru> Date: Sun, 10 May 2020 06:13:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <04298f7d-f2c0-5186-57d3-522e3d886166@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Hi Paul, On 09.05.2020 09:10, Paul Eggert wrote: > On 5/5/20 5:38 AM, Dmitry Gutov wrote: > >> In any case, none of my objections here are strong ones. How about you take the >> proposed patch and update it as you see fit? As long as "constant values" don't >> make a comeback, I'm good. > OK, attached is a draft patch to emacs-27. Although it doesn't go as far as your > patch, it does keep some of it, and in particular it gets rid of the > introduction of the term "constant" to describe objects that should not be > changed. It also omits the "Dangerous" that Drew objected to, and gives an > example of a term that was formerly mutable but is now something that you should > not change. It's an improvement, but still I don't understand your choice. Starting with: Some Lisp objects should never change. For example, you can create a new number by calculating one, but you cannot modify the value of an existing number. You start talking about objects that "should [not] change". And give an example of an object that _cannot_ change. Then, this passage is still confusing, and it doesn't have to be: Although numbers never change and all markers are mutable, a type can be a hybrid with some members mutable and other members not. I could understand it if it was describing an existing type system of the language, or implementation internals, but this is a purely imaginary type system. Why make the mental image harder than we have to? Further down: A mutable object stops being mutable if it is part of an expression that is evaluated. For example, in @code{(eval (list 'quote (list 1)))} the list @code{(1)} was mutable when it was created, but it should not be changed after it was part of an argument to @code{eval}. But the list object didn't change, just an outside reference to its head was created, and that made it "possibly shared", depending on how the aggregated value is subsequently used. And further: ...whereas the call @code{(make-string 3 ?a)} yields a mutable string that can be changed via later calls to @code{aset} The opposite of "mutable" is "immutable". Are quoted strings immutable? They are not. Overall the phrase "that might be shared" is a good replacement. Why not keep to it? The rest of the patch doesn't try so hard to force the new definitions anymore, so your new meaning of "mutable" doesn't seem indispensable. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 May 2020 13:35: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 To: Paul Eggert Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158911766228697 (code B ref 40671); Sun, 10 May 2020 13:35:01 +0000 Received: (at 40671) by debbugs.gnu.org; 10 May 2020 13:34:22 +0000 Received: from localhost ([127.0.0.1]:49213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXm61-0007Sn-L1 for submit@debbugs.gnu.org; Sun, 10 May 2020 09:34:21 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:40365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXm60-0007SV-4W for 40671@debbugs.gnu.org; Sun, 10 May 2020 09:34:20 -0400 Received: by mail-wm1-f53.google.com with SMTP id u16so15672035wmc.5 for <40671@debbugs.gnu.org>; Sun, 10 May 2020 06:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hpdlCunlpfI9pD1/PCLDb05ZxWPO1MeHCzjufbOkuOs=; b=o5FKeh4P9aXWwpSR1MT1kV2lTCrWzZP6SR6dOHoxAkGnvn1lDVQCGiS17mIG7MKHog R2vJI3VFlRAMP8oebs8CRlpge7C3ETeQ5jJwVFcfPToaJrGYeC2Ce+eJMnXhtS/+sIZT QvkTIsDHyApikuftAIDOlZ2xvA/nu9tOHAt1e6xFktKsDMCH8vmKvZOrGA+5K5OCYLnB Uo5SSnVoYo0MtpAWS3T22H4IlouJDT5SWzktZPGFu/2cmO18XHr/tBVc5elKw/68e1/z tSDtr1yl9kiWvdzcSNXpw0qAJegDcrc9jkS64SwjxSOEJRO3kfu9hTdWKHKvuhxkKS1i VMFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hpdlCunlpfI9pD1/PCLDb05ZxWPO1MeHCzjufbOkuOs=; b=rQsItKm38rrA3bGg0rUVjJ5v+6gXR6avkmaSLBikoGVjJnRNraXvAkJSVjM0fGnfTm xbe0qmaO6dsWJP5rlxfT55vRJw3FFFHngdp/6u/LScHwJFobaTW4XrUiUIW8psx/LkIt B2liF5g0FeA8qZ0jx2wc2fk8w128hmC+/6PFnddgRh3XMvZHNXfdNVG1YTVjGQliBrDN LmxmtQTjYGz0YRpwU7yofnqmdj0fR2QvcTvQqzg8O3E2yc1sQbnao/gY8YKmd0cneQRo iRN0rYa9XVE96EXJwtVBOFlg7b2tb8zZDMhmlTS7kSLD68vnyxz4uYot3kkWnv7Q2qvm LIWA== X-Gm-Message-State: AGi0PuZ58iQFvUw9C5lNbJ8GRlQbfb7qq7DpMNX93iNofE9azBCLT/RJ bTD/bsv6ctCzhE0X0Raj8SI= X-Google-Smtp-Source: APiQypJ9kmtSjic15wYpCbki5Wfi5NHPEeNymzjd/cR7pUb+ETfib/L67OBv/xwXuaJGdWsRavtSpg== X-Received: by 2002:a1c:5642:: with SMTP id k63mr26005520wmb.188.1589117654083; Sun, 10 May 2020 06:34:14 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id h2sm4037311wmf.34.2020.05.10.06.34.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 06:34:13 -0700 (PDT) From: Dmitry Gutov 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> Message-ID: Date: Sun, 10 May 2020 16:34:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <88af48c6-bc39-6ab0-59ec-7d537f2d375d@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 10.05.2020 06:13, Dmitry Gutov wrote: > The opposite of "mutable" is "immutable". Are quoted strings immutable? ^ string literals From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 May 2020 17:30: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 To: Dmitry Gutov Cc: ke.vigouroux@laposte.net, Richard Stallman , Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15891317753053 (code B ref 40671); Sun, 10 May 2020 17:30:02 +0000 Received: (at 40671) by debbugs.gnu.org; 10 May 2020 17:29:35 +0000 Received: from localhost ([127.0.0.1]:50380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXple-0000nA-51 for submit@debbugs.gnu.org; Sun, 10 May 2020 13:29:35 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:38446) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXplb-0000mq-9y for 40671@debbugs.gnu.org; Sun, 10 May 2020 13:29:32 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 01AC41600C3; Sun, 10 May 2020 10:29:25 -0700 (PDT) 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 33dXNJLjDn6g; Sun, 10 May 2020 10:29:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9AFBA1600C7; Sun, 10 May 2020 10:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 a5pkyOs67hrG; Sun, 10 May 2020 10:29:22 -0700 (PDT) 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 493811600C3; Sun, 10 May 2020 10:29:22 -0700 (PDT) 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> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <41d69e2e-561f-743a-e1f0-282b2e22b66c@cs.ucla.edu> Date: Sun, 10 May 2020 10:29:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <88af48c6-bc39-6ab0-59ec-7d537f2d375d@yandex.ru> Content-Type: multipart/mixed; boundary="------------312F946E318346DC6D4AB88F" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------312F946E318346DC6D4AB88F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/9/20 8:13 PM, Dmitry Gutov wrote: > You start talking about objects that "should [not] change". And give an example > of an object that _cannot_ change. That's easily altered to also give an example of an object that should not change; see attached patch. > I could understand it if it was describing an existing type system of the > language, or implementation internals, but this is a purely imaginary type > system. objects.texi already talks about the Emacs Lisp type system and specifically mentions strings, conses, etc. as types. Even if one considers the Emacs Lisp type system to be "imaginary", it's reasonable to use the documentation's already-existing terminology here. > the list object didn't change, just an outside reference to its head was > created, The attached patch alters the example so that the list object does change (or at least tries to). > The opposite of "mutable" is "immutable". Are string literals immutable? They are > not. They might be mutable, and they might not be. The documentation deliberately doesn't say, because we don't want to document the details (they have changed in the past and are likely to change in the future). > Overall the phrase "that might be shared" is a good replacement. Why not keep to > it? Because it's not an accurate statement of the problem. The set of objects that might be shared differs from the set of objects that should not change. The Mutability node focuses on the latter set of objects, and gives the former as an example but it is not the only sort of object that should not change. > your new meaning of "mutable" doesn't seem indispensable. That bar is too high, as hardly anything in the manual is *indispensable*. Ihe notion of mutability is good to have in the manual, as it reduces confusion and helps in documentation elsewhere. That's good enough. I'm attaching two patches. The first are the changes mentioned above, and the second is a single patch that combines the first patch with the changes I previously proposed. --------------312F946E318346DC6D4AB88F Content-Type: text/x-patch; charset=UTF-8; name="0001-Update-mutability-doc.patch" Content-Disposition: attachment; filename="0001-Update-mutability-doc.patch" Content-Transfer-Encoding: quoted-printable >From f2f7cff7c72ca399ca49a50ceac660c3b0991d92 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 May 2020 10:01:46 -0700 Subject: [PATCH] Update mutability doc MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit * doc/lispref/objects.texi (Mutability): Revise in response to Dmitry Gutov=E2=80=99s comments (Bug#40671#420). --- doc/lispref/objects.texi | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index a0afadc2d7..7727a630dd 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2379,26 +2379,37 @@ Mutability @section Mutability @cindex mutable objects =20 - Some Lisp objects should never change. For example, you can create -a new number by calculating one, but you cannot modify the value of an -existing number. + 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, +although you can create a new number by calculating one, Lisp provides +no operation to change the value of an existing number. =20 Other Lisp objects are @dfn{mutable}: it is safe to change their values via destructive operations involving side effects. For example, an existing marker can be changed by moving the marker to point to somewhere else. =20 - Although numbers never change and all markers are mutable, a type -can be a hybrid with some members mutable and other members not. These -types include conses, vectors, strings, and symbols. For example, the s= tring -literal @code{"aaa"} yields a string that should not be changed, whereas= the -call @code{(make-string 3 ?a)} yields a mutable string that can be + 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}. =20 A mutable object stops being mutable if it is part of an expression -that is evaluated. For example, in @code{(eval (list 'quote (list 1)))} -the list @code{(1)} was mutable when it was created, but it should not -be changed after it was part of an argument to @code{eval}. The +that is evaluated. For example: + +@example +(let* ((x (list 0.5)) + (y (eval (list 'quote x)))) + (setcar x 1.5) ;; The program should not do this. + y) +@end example + +@noindent +Although the list @code{(0.5)} was mutable when it was created, it shoul= d not +have been changed via @code{setcar} because it given to @code{eval}. Th= e reverse does not occur: an object that should not be changed never becomes mutable afterwards. =20 --=20 2.17.1 --------------312F946E318346DC6D4AB88F Content-Type: text/x-patch; charset=UTF-8; name="0001-Don-t-use-constant-for-values-you-shouldn-t-change.patch" Content-Disposition: attachment; filename*0="0001-Don-t-use-constant-for-values-you-shouldn-t-change.patc"; filename*1="h" Content-Transfer-Encoding: quoted-printable >From 1ddbbfd38c280822d1bed3c1281909fbfea1f54f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 May 2020 09:27:02 -0700 Subject: [PATCH] =3D?UTF-8?q?Don=3DE2=3D80=3D99t=3D20use=3D20=3DE2=3D80=3D= 9Cconstant?=3D =3D?UTF-8?q?=3DE2=3D80=3D9D=3D20for=3D20values=3D20you=3D20shouldn=3DE2=3D= 80=3D99t=3D20change?=3D MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Inspired by patch proposed by Dmitry Gutov (Bug#40671#393) and by his further comments (Bug#40671#420). * doc/lispintro/emacs-lisp-intro.texi (setcar): Don=E2=80=99t push mutability here. * doc/lispref/eval.texi (Self-Evaluating Forms, Quoting) (Backquote): * doc/lispref/lists.texi (Modifying Lists): * doc/lispref/objects.texi (Lisp Data Types, Mutability): * doc/lispref/sequences.texi (Array Functions, Vectors): * doc/lispref/strings.texi (String Basics, Modifying Strings): Don=E2=80=99t use the word =E2=80=9Cconstant=E2=80=9D to describe all val= ues that a program should not change. * doc/lispref/objects.texi (Mutability): Rename from =E2=80=9CConstants and Mutability=E2=80=9D. All uses changed= . In a footnote, contrast the Emacs behavior with that of Common Lisp, Python, etc. for clarity, and say the goal is to be nicer. Update mutability doc * doc/lispref/objects.texi (Mutability): Revise in response to Dmitry Gutov=E2=80=99s comments (Bug#40671#420). --- doc/lispintro/emacs-lisp-intro.texi | 5 +- doc/lispref/elisp.texi | 2 +- doc/lispref/eval.texi | 21 +++---- doc/lispref/lists.texi | 16 ++--- doc/lispref/objects.texi | 90 +++++++++++++++-------------- doc/lispref/sequences.texi | 25 ++++---- doc/lispref/strings.texi | 11 ++-- 7 files changed, 83 insertions(+), 87 deletions(-) diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-li= sp-intro.texi index ea16d9ef15..46462162ca 100644 --- a/doc/lispintro/emacs-lisp-intro.texi +++ b/doc/lispintro/emacs-lisp-intro.texi @@ -7317,8 +7317,6 @@ setcar works is to experiment. We will start with the @code{setcar} function. =20 @need 1200 -@cindex constant lists -@cindex mutable lists First, we can make a list and then set the value of a variable to the list, using the @code{setq} special form. Because we intend to use @code{setcar} to change the list, this @code{setq} should not use the @@ -7327,8 +7325,7 @@ setcar tried to change part of the program while running it. Generally speaking an Emacs Lisp program's components should be constant (or unchanged) while the program is running. So we instead construct an -animal list that is @dfn{mutable} (or changeable) by using the -@code{list} function, as follows: +animal list by using the @code{list} function, as follows: =20 @smallexample (setq animals (list 'antelope 'giraffe 'lion 'tiger)) diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi index bba1b63115..9a6796790c 100644 --- a/doc/lispref/elisp.texi +++ b/doc/lispref/elisp.texi @@ -297,7 +297,7 @@ Top * Circular Objects:: Read syntax for circular structure. * Type Predicates:: Tests related to types. * Equality Predicates:: Tests of equality between any two objects. -* Constants and Mutability:: Whether an object's value can change. +* Mutability:: Some objects should not be modified. =20 Programming Types =20 diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi index baddce4d9c..39f342a798 100644 --- a/doc/lispref/eval.texi +++ b/doc/lispref/eval.texi @@ -158,11 +158,11 @@ Self-Evaluating Forms @end group @end example =20 - A self-evaluating form yields constant conses, vectors and strings, an= d you -should not attempt to modify their contents via @code{setcar}, @code{ase= t} or + A self-evaluating form yields a value that becomes part of the program= , +and you should not try to modify it via @code{setcar}, @code{aset} or similar operations. The Lisp interpreter might unify the constants yielded by your program's self-evaluating forms, so that these -constants might share structure. @xref{Constants and Mutability}. +constants might share structure. @xref{Mutability}. =20 It is common to write numbers, characters, strings, and even vectors in Lisp code, taking advantage of the fact that they self-evaluate. @@ -564,8 +564,8 @@ Quoting =20 @defspec quote object This special form returns @var{object}, without evaluating it. -The returned value is a constant, and should not be modified. -@xref{Constants and Mutability}. +The returned value might be shared and should not be modified. +@xref{Self-Evaluating Forms}. @end defspec =20 @cindex @samp{'} for quoting @@ -608,9 +608,9 @@ Quoting =20 Although the expressions @code{(list '+ 1 2)} and @code{'(+ 1 2)} both yield lists equal to @code{(+ 1 2)}, the former yields a -freshly-minted mutable list whereas the latter yields a constant list -built from conses that may be shared with other constants. -@xref{Constants and Mutability}. +freshly-minted mutable list whereas the latter yields a list +built from conses that might be shared and should not be modified. +@xref{Self-Evaluating Forms}. =20 Other quoting constructs include @code{function} (@pxref{Anonymous Functions}), which causes an anonymous lambda expression written in Lisp @@ -710,8 +710,9 @@ Backquote @end example =20 If a subexpression of a backquote construct has no substitutions or -splices, it acts like @code{quote} in that it yields constant conses, -vectors and strings that should not be modified. +splices, it acts like @code{quote} in that it yields conses, +vectors and strings that might be shared and should not be modified. +@xref{Self-Evaluating Forms}. =20 @node Eval @section Eval diff --git a/doc/lispref/lists.texi b/doc/lispref/lists.texi index fcaf4386b1..ae793d5e15 100644 --- a/doc/lispref/lists.texi +++ b/doc/lispref/lists.texi @@ -873,8 +873,8 @@ Modifying Lists operations because they change existing list structure. Destructive operations should be applied only to mutable lists, that is, lists constructed via @code{cons}, @code{list} or similar -operations. Lists created by quoting are constants and should not be -changed by destructive operations. @xref{Constants and Mutability}. +operations. Lists created by quoting are part of the program and +should not be changed by destructive operations. @xref{Mutability}. =20 @cindex CL note---@code{rplaca} vs @code{setcar} @quotation @@ -911,7 +911,7 @@ Setcar =20 @example @group -(setq x (list 1 2)) ; @r{Create a mutable list.} +(setq x (list 1 2)) @result{} (1 2) @end group @group @@ -931,7 +931,7 @@ Setcar =20 @example @group -;; @r{Create two mutable lists that are partly shared.} +;; @r{Create two lists that are partly shared.} (setq x1 (list 'a 'b 'c)) @result{} (a b c) (setq x2 (cons 'z (cdr x1))) @@ -1022,11 +1022,11 @@ Setcdr =20 @example @group -(setq x (list 1 2 3)) ; @r{Create a mutable list.} +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group -(setcdr x '(4)) ; @r{Modify the list's tail to be a constant list.} +(setcdr x '(4)) @result{} (4) @end group @group @@ -1135,11 +1135,11 @@ Rearrangement =20 @example @group -(setq x (list 1 2 3)) ; @r{Create a mutable list.} +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group -(nconc x '(4 5)) ; @r{Modify the list's tail to be a constant list.} +(nconc x '(4 5)) @result{} (1 2 3 4 5) @end group @group diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 1d5b2c690f..7727a630dd 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -46,10 +46,6 @@ Lisp Data Types Lisp variables can only take on values of a certain type. @xref{Variables with Restricted Values}.) =20 - Some Lisp objects are @dfn{constant}: their values should never change= . -Others are @dfn{mutable}: their values can be changed via destructive -operations that involve side effects. - This chapter describes the purpose, printed representation, and read syntax of each of the standard types in GNU Emacs Lisp. Details on how to use these types can be found in later chapters. @@ -63,7 +59,7 @@ Lisp Data Types * Circular Objects:: Read syntax for circular structure. * Type Predicates:: Tests related to types. * Equality Predicates:: Tests of equality between any two object= s. -* Constants and Mutability:: Whether an object's value can change. +* Mutability:: Some objects should not be modified. @end menu =20 @node Printed Representation @@ -2379,51 +2375,59 @@ Equality Predicates @end example @end defun =20 -@node Constants and Mutability -@section Constants and Mutability -@cindex constants +@node Mutability +@section Mutability @cindex mutable objects =20 - Some Lisp objects are constant: their values should never change -during a single execution of Emacs running well-behaved Lisp code. -For example, you can create a new integer by calculating one, but you -cannot modify the value of an existing integer. - - Other Lisp objects are mutable: it is safe to change their values -via destructive operations involving side effects. For example, an -existing marker can be changed by moving the marker to point to -somewhere else. - - Although all numbers are constants and all markers are -mutable, some types contain both constant and mutable members. These -types include conses, vectors, strings, and symbols. For example, the s= tring -literal @code{"aaa"} yields a constant string, whereas the function -call @code{(make-string 3 ?a)} yields a mutable string that can be + 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, +although you can create a new number by calculating one, Lisp provides +no operation to change the value of an existing number. + + Other Lisp objects are @dfn{mutable}: it is safe to change their +values via destructive operations involving side effects. For +example, an existing marker can be changed by moving the marker to +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, 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}. =20 - A mutable object can become constant if it is part of an expression -that is evaluated. The reverse does not occur: constant objects -should stay constant. + A mutable object stops being mutable if it is part of an expression +that is evaluated. For example: + +@example +(let* ((x (list 0.5)) + (y (eval (list 'quote x)))) + (setcar x 1.5) ;; The program should not do this. + y) +@end example + +@noindent +Although the list @code{(0.5)} was mutable when it was created, it shoul= d not +have been changed via @code{setcar} because it given to @code{eval}. Th= e +reverse does not occur: an object that should not be changed never +becomes mutable afterwards. =20 Trying to modify a constant variable signals an error (@pxref{Constant Variables}). -A program should not attempt to modify other types of constants because = the -resulting behavior is undefined: the Lisp interpreter might or might -not detect the error, and if it does not detect the error the -interpreter can behave unpredictably thereafter. Another way to put -this is that although mutable objects are safe to change and constant -variables reliably prevent attempts to change them, other constants -are not safely mutable: if a misbehaving program tries to change such a -constant then the constant's value might actually change, or the -program might crash or worse. This problem occurs -with types that have both constant and mutable members, and that have -mutators like @code{setcar} and @code{aset} that are valid on mutable -objects but hazardous on constants. - - When the same constant occurs multiple times in a program, the Lisp -interpreter might save time or space by reusing existing constants or -constant components. For example, @code{(eq "abc" "abc")} returns +If a program attempts to change other objects that should not be +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 +JavaScript and Python where an interpreter is required to signal an +error if a program attempts to change a constant. Ideally the Emacs +Lisp interpreter will evolve in latter direction.} + + 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 @code{t} if the interpreter creates only one instance of the string -constant @code{"abc"}, and returns @code{nil} if it creates two +literal @code{"abc"}, and returns @code{nil} if it creates two instances. Lisp programs should be written so that they work regardless of whether this optimization is in use. diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi index 1cb0d05cc7..91c3049f87 100644 --- a/doc/lispref/sequences.texi +++ b/doc/lispref/sequences.texi @@ -183,11 +183,11 @@ Sequence Functions =20 @example @group -(setq bar (list 1 2)) ; @r{Create a mutable list.} +(setq bar (list 1 2)) @result{} (1 2) @end group @group -(setq x (vector 'foo bar)) ; @r{Create a mutable vector.} +(setq x (vector 'foo bar)) @result{} [foo (1 2)] @end group @group @@ -278,7 +278,7 @@ Sequence Functions =20 @example @group -(setq x (list 'a 'b 'c)) ; @r{Create a mutable list.} +(setq x (list 'a 'b 'c)) @result{} (a b c) @end group @group @@ -320,7 +320,7 @@ Sequence Functions For the vector, it is even simpler because you don't need setq: =20 @example -(setq x (copy-sequence [1 2 3 4])) ; @r{Create a mutable vector.} +(setq x (copy-sequence [1 2 3 4])) @result{} [1 2 3 4] (nreverse x) @result{} [4 3 2 1] @@ -331,6 +331,7 @@ Sequence Functions Note that unlike @code{reverse}, this function doesn't work with strings= . Although you can alter string data by using @code{aset}, it is strongly encouraged to treat strings as immutable even when they are mutable. +@xref{Mutability}. =20 @end defun =20 @@ -374,7 +375,7 @@ Sequence Functions =20 @example @group -(setq nums (list 1 3 2 6 5 4 0)) ; @r{Create a mutable list.} +(setq nums (list 1 3 2 6 5 4 0)) @result{} (1 3 2 6 5 4 0) @end group @group @@ -1228,7 +1229,7 @@ Array Functions =20 @example @group -(setq w (vector 'foo 'bar 'baz)) ; @r{Create a mutable vector.} +(setq w (vector 'foo 'bar 'baz)) @result{} [foo bar baz] (aset w 0 'fu) @result{} fu @@ -1237,7 +1238,7 @@ Array Functions @end group =20 @group -;; @r{@code{copy-sequence} creates a mutable string.} +;; @r{@code{copy-sequence} copies the string to be modified later.} (setq x (copy-sequence "asdfasfd")) @result{} "asdfasfd" (aset x 3 ?Z) @@ -1247,9 +1248,7 @@ Array Functions @end group @end example =20 -The @var{array} should be mutable; that is, it should not be a constant, -such as the constants created via quoting or via self-evaluating forms. -@xref{Constants and Mutability}. +The @var{array} should be mutable. @xref{Mutability}. =20 If @var{array} is a string and @var{object} is not a character, a @code{wrong-type-argument} error results. The function converts a @@ -1262,7 +1261,6 @@ Array Functions =20 @example @group -;; @r{Create a mutable vector and then fill it with zeros.} (setq a (copy-sequence [a b c d e f g])) @result{} [a b c d e f g] (fillarray a 0) @@ -1271,7 +1269,6 @@ Array Functions @result{} [0 0 0 0 0 0 0] @end group @group -;; @r{Create a mutable string and then fill it with "-".} (setq s (copy-sequence "When in the course")) @result{} "When in the course" (fillarray s ?-) @@ -1310,8 +1307,8 @@ Vectors evaluation: the result of evaluating it is the same vector. This does not evaluate or even examine the elements of the vector. @xref{Self-Evaluating Forms}. Vectors written with square brackets -are constants and should not be modified via @code{aset} or other -destructive operations. @xref{Constants and Mutability}. +should not be modified via @code{aset} or other destructive +operations. @xref{Mutability}. =20 Here are examples illustrating these principles: =20 diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi index a4c9c2549c..70c3b3cf4b 100644 --- a/doc/lispref/strings.texi +++ b/doc/lispref/strings.texi @@ -49,10 +49,9 @@ String Basics =20 Since strings are arrays, and therefore sequences as well, you can operate on them with the general array and sequence functions documented -in @ref{Sequences Arrays Vectors}. For example, you can access or -change individual characters in a string using the functions @code{aref} -and @code{aset} (@pxref{Array Functions}). However, you should not -try to change the contents of constant strings (@pxref{Modifying Strings= }). +in @ref{Sequences Arrays Vectors}. For example, you can access +individual characters in a string using the function @code{aref} +(@pxref{Array Functions}). =20 There are two text representations for non-@acronym{ASCII} characters in Emacs strings (and in buffers): unibyte and multibyte. @@ -382,9 +381,7 @@ Modifying Strings @cindex string modification =20 You can alter the contents of a mutable string via operations -described in this section. However, you should not try to use these -operations to alter the contents of a constant string. -@xref{Constants and Mutability}. +described in this section. @xref{Mutability}. =20 The most basic way to alter the contents of an existing string is with @code{aset} (@pxref{Array Functions}). @code{(aset @var{string} --=20 2.17.1 --------------312F946E318346DC6D4AB88F-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects 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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Dmitry Gutov Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158915525731876 (code B ref 40671); Mon, 11 May 2020 00:01:02 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 00:00:57 +0000 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 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 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 From: Michael Heerdegen 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> Date: Mon, 11 May 2020 02:00:15 +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") Message-ID: <87mu6ftk6o.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:Y1IQt57Z9Y01ntGLY/2NUDxm8eHwJ85jOhjuESkYfX7//XpYUpO mu/HgkcHOGjQO45BXwXuCxrG9GGtb0LW7JfdD/9HQdVJ66cewTpBBlnZm/yUok4hjQToX/A kajIGV3GCbJbBz+XES4AsHE7Q98UUnlJuhwLZa+WBepzEPsZGCwWB0+khv/fKFqpd80Yph4 qcl+f4jmGPbvDC96fRMWA== X-Spam-Flag: NO 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/XlJ7w93746fxBZjNJhOWwNgPKhYUOeWIgkTumJAi6SC2UYkUBaQIyHgrVWeMjTYQPs 0AHa9qv45PZ8dybuTjHcQQH0Ppa8aiEaWVcV4tTwbq1p2//Zveu+HWP+cAmUxbocpY7zkLn5d K2nByx9IR9wIuMdUfrjydO36oFuOEW2Yqlf2Pp812CXUZcKCcyPMIGveBM7Yqe9ehO52myzBV Zjiz5FEk/MCU0VTFIAjksFb5cg4eBBE+1kcluZoYDpu6WVYEUFvmmTsjryYAzRZTYxbGbOFdN mrVhK/8F6yQ8hXhKNwyIX54T52leaeDYJSFeGYubP+LuMTqfqPnoX9LFCKm/oub1i2Du3G3IO X9b4tfb9PsshA5yUpm2LPDvO3/ZL7YPFQLnea08u3qRCmXzu11BNJuUKuLh+aEjCVk74eT4w/ mU6iYJJG/vU6ExwoNyQB70Gbbmm6p7vDthNyxlwFjlpoDbPlcxY470xc1dHtqToArK0Gl0hrx rND2OTXRGHz5A6bhE X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 00:28: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 To: Michael Heerdegen , Paul Eggert Cc: ke.vigouroux@laposte.net, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15891568292493 (code B ref 40671); Mon, 11 May 2020 00:28:01 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 00:27:09 +0000 Received: from localhost ([127.0.0.1]:50730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXwHl-0000e8-Fl for submit@debbugs.gnu.org; Sun, 10 May 2020 20:27:09 -0400 Received: from mail-wm1-f47.google.com ([209.85.128.47]:37127) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXwHk-0000dq-3F for 40671@debbugs.gnu.org; Sun, 10 May 2020 20:27:08 -0400 Received: by mail-wm1-f47.google.com with SMTP id z72so7625906wmc.2 for <40671@debbugs.gnu.org>; Sun, 10 May 2020 17:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=elNaZsLOHpn3N6Z726ptlxXPrATLay7TJ3g3wAtL2tU=; b=W3SDiqNESTcNeobEPjaCzGmTgEOsyRNvGIsS+SC5RoR3i4JPW7oE9b/cxLvjyf1jRm x/7BSldnY35buTS9rOuEm9qfguAP+K9RybWntwpYJvkTIPLNrRxTeojNE6eCUMfzJLJC anJQ415uLKg4Rq+hfZbtjZ2qA6w6yvsjv/tI+HnT4l2tNjqHayCe6bLVGT6CV0HYPbj0 +lbY0Of91BzPUE5c2uMSNclizdS8v5/snGgAu8mZHId+GdabIQ518IEjbpyojTfPA2iR 1cgnkZMPgbYfCKQh8d8pk6nQNF59gMAMrKpwUlEg5JG8nTZd6CllLIBar/L7ClciQJY9 3KuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=elNaZsLOHpn3N6Z726ptlxXPrATLay7TJ3g3wAtL2tU=; b=RP6r/GuGs97QWBFvcXOKV7q27fcdk5Otk7EM2AuEWolJGWzTm4djXtPqdEpj8jcnaw 1uS7HB1KdL8uFOqJ/DU6qyLlgHQXuXp9Xhjotp8xn0GjOUs46kkiaUbu+hp8V2HS/tG4 Wg/l9XsRMWiDEP65ST+osM1Ic3sdaptjAL99XbiUQSkpL5VHXB0K40fg0FnGEO41GWTQ jDcW6OzEvwk+B5n5jBvLsK6My5tqo4nqwjRXn10aIIHv7QfbZKVQmsxI15WIDCbiUQWO O6oB8EZIH3OZxJ4rx52E6Ur35Hrv37sasgJ8uoZwjKBjH4rne09NTcFzhFcQA4n65uIC wmrg== X-Gm-Message-State: AGi0PuYi9yjK7y5zOssESODKGUIEayDxxUHb91yMwSXCf0cSuciYTSMe OjuXUhp2ODYpjl1CU/EZ4RQ= X-Google-Smtp-Source: APiQypKe1Vk54iPWZAkeeeBfJHxOwPAx4ZmXcrf52S9L8W1vYlBq0ZS+EnfxUTB/6kITqHpfhfLqIA== X-Received: by 2002:a1c:7513:: with SMTP id o19mr25828690wmc.9.1589156822183; Sun, 10 May 2020 17:27:02 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id r11sm13691748wrv.14.2020.05.10.17.27.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 17:27:01 -0700 (PDT) References: <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> <87mu6ftk6o.fsf@web.de> From: Dmitry Gutov Message-ID: <83ff79aa-0b79-e61a-93b3-c88bbdc322db@yandex.ru> Date: Mon, 11 May 2020 03:26:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87mu6ftk6o.fsf@web.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Thanks, Michael, +1 on your points, but this one especially: On 11.05.2020 03:00, Michael Heerdegen wrote: >> + 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. "safely mutable" definitely sounds better to me. And while we might use the shorthand "mutable" in the corresponding section, while referring to this notion outside of it, it would be better to use the full two-word version. >> + 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? FWIW, CLtL seems to use a clunky term "similar as constants" for this. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 00:46: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, Richard Stallman , Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15891579094855 (code B ref 40671); Mon, 11 May 2020 00:46:02 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 00:45:09 +0000 Received: from localhost ([127.0.0.1]:50749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXwZA-0001GF-Jf for submit@debbugs.gnu.org; Sun, 10 May 2020 20:45:08 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:34359) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXwZ8-0001FM-TQ for 40671@debbugs.gnu.org; Sun, 10 May 2020 20:45:07 -0400 Received: by mail-wm1-f54.google.com with SMTP id g14so5620971wme.1 for <40671@debbugs.gnu.org>; Sun, 10 May 2020 17:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=q1+rs7Ny35oWvgQpo/yN2mSgE1Iz4HqzU/5kdQZuEAo=; b=O0BsD8AzUlsdDaNHrf4a6b/OGoU8X7QuhK2Ef9BA7BseYqr/TLSWQwUzqOx6b7BsyX GKjhxheRm+uNevQwcXHIteATiP+qwI+Gj2C2jwZts7oIkhkvkLu2P8+G7p4ttAl33//t h1tc13hwxN8JPE4rJFKd6Ul5LC4q+bhaeGBbDToFgpoO6WJ+x73NO5ywcNBbXFgPlAPa F57KGRRUtnnC4UnfDb6PhZpN5X/lGq2hOsCu+PiniB1GMqTxdeRj/kDeCUI5+xw/1ny7 pj8dW46EJUSZT64acpoM29BP6uo1OKsz64XTaz5nsr0TG1LwaQy0MoiZ8lKQISYv9Yx+ ezYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q1+rs7Ny35oWvgQpo/yN2mSgE1Iz4HqzU/5kdQZuEAo=; b=Lo8QG4Q6opsMYliDJbywTGFHmIy3yaAvB96CvQjOSx6JDcYgD+sTgPxlWGzrnGCb0f y1T4/6QwyZgFOwDq48BfgWJO1vvvuY9KD5SsvwpwTwcM/cJaKx7PoXc881KrNowlUgGz xVnMo2zwsbnt6LluTpmM0G8FnNWZn1/0DeAFtNSFngDi3cmKjkO4rOF/DonNUb9B+Ft5 pdm2pwy2Mp4N2sms7lsweiC0WYld8BkQbHc6M1vz7zDu+8fMPbUbJuiVpOAm5o806ZkP A9PAgNm+eMOTx8xm2QKCGyHztXxB/iYHyvyVC/NldknftQjXGBOS0iqcQW/MeQiP1T4Q b/5A== X-Gm-Message-State: AGi0PuYG6W8elzMeqhXey9IPXUMauPuQdeKl2kNNJcFTJfsuND5fdJsG +4cwRGuqF7wwe6fpOj+N8Wk= X-Google-Smtp-Source: APiQypKbtk3iBj2O+htY5KKip1qaMNTQSkIxWOckJvAGGt0qrLel7TYQID2Bu/jAzaqRkdf3YhkafQ== X-Received: by 2002:a1c:e4c1:: with SMTP id b184mr11957895wmh.4.1589157900914; Sun, 10 May 2020 17:45:00 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id z6sm9007249wrq.1.2020.05.10.17.44.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 17:45:00 -0700 (PDT) References: <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> From: Dmitry Gutov Message-ID: Date: Mon, 11 May 2020 03:44:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <41d69e2e-561f-743a-e1f0-282b2e22b66c@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 10.05.2020 20:29, Paul Eggert wrote: > On 5/9/20 8:13 PM, Dmitry Gutov wrote: > >> You start talking about objects that "should [not] change". And give an example >> of an object that _cannot_ change. > > That's easily altered to also give an example of an object that should not > change; see attached patch. Quoting the new paragraph. Now it goes "should not" -> "cannot": + 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, +although you can create a new number by calculating one, Lisp provides +no operation to change the value of an existing number. "Indeed"? >> I could understand it if it was describing an existing type system of the >> language, or implementation internals, but this is a purely imaginary type >> system. > > objects.texi already talks about the Emacs Lisp type system and specifically > mentions strings, conses, etc. as types. Even if one considers the Emacs Lisp > type system to be "imaginary", it's reasonable to use the documentation's > already-existing terminology here. Strings, conses, etc, are anything but imaginary (try using one in a function that expects another, and you'll almost always get a runtime error). The changing "mutability" status is imaginary, however. This also requires the reader to read the manual without missing a reference. A regular person would not understand your meaning of "mutable" without following the reference to {Mutability}. Which not everybody is going to do, and which is harder to do when reading a printed version. >> the list object didn't change, just an outside reference to its head was >> created, > > The attached patch alters the example so that the list object does change (or at > least tries to). Does is ignore the possibility of the example in the previous version, then? >> The opposite of "mutable" is "immutable". Are string literals immutable? They are >> not. > > They might be mutable, and they might not be. The documentation deliberately > doesn't say, because we don't want to document the details (they have changed in > the past and are likely to change in the future). I'm trying to point out the incompatibility with the regular meanings of the words used. Also see Michael's suggestion. >> Overall the phrase "that might be shared" is a good replacement. Why not keep to >> it? > > Because it's not an accurate statement of the problem. The set of objects that > might be shared differs from the set of objects that should not change. The > Mutability node focuses on the latter set of objects, and gives the former as an > example but it is not the only sort of object that should not change. But if we don't mention such cases in "Mutability", where do we cover them? I'm also looking at the new example: +(let* ((x (list 0.5)) + (y (eval (list 'quote x)))) + (setcar x 1.5) ;; The program should not do this. + y) Why is this a problem? Do we expect this it could lead to a segfault? Evaluating this expression in IELM leads to a stable result. Putting it in a function doesn't bring any surprises either. Example: ELISP> (defun test (v) (let* ((x (list v)) (y (eval (list 'quote x)))) (setcar x 1.5) y)) test ELISP> (test 3) (1.5) It's an advanced, yes, but clearly the expected behavior if someone wrote a function like that. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 01:49: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 To: Michael Heerdegen , Paul Eggert Cc: ke.vigouroux@laposte.net, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , Dmitry Gutov Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158916168211749 (code B ref 40671); Mon, 11 May 2020 01:49:01 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 01:48:02 +0000 Received: from localhost ([127.0.0.1]:50789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxY1-00033M-To for submit@debbugs.gnu.org; Sun, 10 May 2020 21:48:02 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:55968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxXz-00032t-52 for 40671@debbugs.gnu.org; Sun, 10 May 2020 21:48:00 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04B1lhIL032545; Mon, 11 May 2020 01:47:43 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=ctzBK2muA5ixTLBZIXKeOdzVuKW2wxiQKsGgNQIdpV8=; b=nHONRWMziSLKoUVkh1i5WxGALRIwbExIDg8v1j1T+zV07cqamxM1F/PWQVio6heA/daT 4I4P5kRzuXNrKj0rkmTrwNAUP0EgV1a+CAnmW/m4yj40XhEUzdw/N/TmOF1drQ/UK1Vz ewWzFbLLRYR6Jz69Z3MtBgI8eSb12W/UGRbSlBAJmIdijIEeiq/7CrIdYq/7Wav20T8a nClVYZbdMiAldKGiyhLTkbcFnx/5AlmglC+ESO6szJ3qTRJXWd1gNjoTT9zig/oI/cIt nboODr1AqtJmFMQdHy3w9IvT+xpofeNmqa50X21EkNxrJTIQrkodGGMTvu+cIy6ib2I/ NQ== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 30x3mbjd6r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 11 May 2020 01:47:42 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04B1iN4V120400; Mon, 11 May 2020 01:47:42 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 30xbgc6raa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 May 2020 01:47:41 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 04B1lQGZ026647; Mon, 11 May 2020 01:47:28 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 10 May 2020 18:47:25 -0700 (PDT) From: Drew Adams 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> <87mu6ftk6o.fsf@web.de> In-Reply-To: <87mu6ftk6o.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 spamscore=0 suspectscore=18 phishscore=0 bulkscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110012 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 impostorscore=0 mlxscore=0 suspectscore=18 bulkscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110012 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Symbols are constant AFAICT, their bindings > are not (variables are not constant). Their bindings as variables are not constant, except for keyword symbols, nil, and t (are there any others?). But are symbols otherwise constant, besides their values? Depends what you mean by "symbol", perhaps. Certainly you can change not only `symbol-value' but also `symbol-function' and `symbol-plist'. I don't see symbols as very constant. [Personally, as I suggested, I don't think the text about this gotcha should get down in the weeds about mutable/immutable anything. I think it should stay general, not try to catalog specific problems (e.g. strings, conses, whatever). It should show and explain a very simple example of what can happen with a quoted list, and then leave it at that. Maybe it should mention, as you said a while back, that there are the reader, interpreter, and byte compiler, when saying something about the problem in general. But I already said all this, and I said I was done here...] BTW, in Common Lisp you can even do nasty things like modify the `symbol-name' of a symbol. For that, CLTL2 says:=20 "It is an extremely bad idea to modify a string being used as the print name of a symbol. Such a modification may tremendously confuse the function `read' and the package system." That's the _kind_ of somewhat vague gotcha description I think we should have. Enough to let users know they don't want to do it. > > + A mutable object stops being mutable if it is part of an > expression > > +that is evaluated. For example: >=20 > 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=20 I don't recall saying that, but I may have. Not sure what's meant here. I objected to using "dangerous", as if the gotcha was generally hazardous to life. > 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. To me, the problem for users is not so much that Emacs can crash as it is that they may lose data. Or more likely (and worth mentioning, I think, as a motivator) that they might have a heck of a time trying to figure out why their code doesn't seem to behave as they expect. Seeing a quoted list in source code can make you think new list structure is created each time that code is run. Code "initializing" part of some list structure to a quoted list might give you the impression that that's what happens each time (e.g. each time a function that seems to do that gets called), but the same cons from a first evaluation (or reading) of that quoted list might remain in use for each invocation of the function. And if you at some point modify that cons then you might not get your apparent "initialization" to that quoted list each time the function's invoked. > > + 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. >=20 > 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? I think that text wasn't too bad, but I see your point. And it's especially not good to use "value" in the two different senses, as (1) something you see ("appears") in a source program and (2) a runtime value that results from reading, byte-compiling, or interpreting that source code. Maybe "object" or "Lisp object" instead of "value", for #2? (Note: I didn't read the full text. I'm just reacting to what was cited in your mail. Sorry.) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 01:54: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 To: Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Dmitry Gutov Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158916200012368 (code B ref 40671); Mon, 11 May 2020 01:54:01 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 01:53:20 +0000 Received: from localhost ([127.0.0.1]:50793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxd8-0003DO-Tc for submit@debbugs.gnu.org; Sun, 10 May 2020 21:53:20 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxd4-0003DA-Rv for 40671@debbugs.gnu.org; Sun, 10 May 2020 21:53:16 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5154C1600AF; Sun, 10 May 2020 18:53:09 -0700 (PDT) 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 BoQCjhbJvr0V; Sun, 10 May 2020 18:53:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E73121600C7; Sun, 10 May 2020 18:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 BTZveQ6b_xMn; Sun, 10 May 2020 18:53:06 -0700 (PDT) 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 91AA11600AF; Sun, 10 May 2020 18:53:06 -0700 (PDT) References: <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> <87mu6ftk6o.fsf@web.de> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <81f50f04-b5f8-12de-9171-f9660801c5ab@cs.ucla.edu> Date: Sun, 10 May 2020 18:53:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87mu6ftk6o.fsf@web.de> Content-Type: multipart/mixed; boundary="------------7E62896F175FD42241D7F338" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------7E62896F175FD42241D7F338 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/10/20 5:00 PM, Michael Heerdegen wrote: > Are there any classes of "types" where all members are always mutable? Markers, for one. (This is mentioned in the previous paragraph.) There are others. We needn't list them all here. > 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). All good points. The simplest fix is to not mention symbol bindings here, as they're a complicated topic. Their mutability issues can be documented later, if someone wants to tackle the subject. > 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. I think that's pretty much already done, since the definition of "mutable" says "it is safe to change their values". I'd rather not use the term "safely mutable" everywhere, as I don't want the manual to push the idea of "safely mutable" as opposed to "mutable"; instead, I want the manual to look forward to a future version where objects are either mutable or are immutable (and the latter is checked by the interpreter). >> + 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). They can if one feeds the values into 'eval', which runs part of a program. And 'read' can read programs. So I'm not sure I get the distinction. > Is it always the interpreter that > does this mapping? This section is written at a high level and uses "interpreter" to refer to the whole Emacs Lisp system. (This usage is longstanding in the manual.) So if any mapping is being done, it's by the "interpreter" in that sense. > "Same syntax" is not good as well: I don't see that phrase used in the manual. I assume you meant "same values"? > (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? I changed it to use "parts of a program" and I can changed the "values" to "constants". Further patch attached; it also attempts to address the issues raised by Dmitry and Drew recently. I'm also attaching a single patch that accumulates it into all the patches proposed for emacs-27. --------------7E62896F175FD42241D7F338 Content-Type: text/x-patch; charset=UTF-8; name="0001-doc-lispref-objects.texi-Mutability-More-tweaking.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-doc-lispref-objects.texi-Mutability-More-tweaking.patch" >From 3b200efd127a71c584dcb8942febc34021dffd22 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 May 2020 18:44:46 -0700 Subject: [PATCH] * doc/lispref/objects.texi (Mutability): More tweaking. --- doc/lispref/objects.texi | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 7727a630dd..136213ad66 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2392,10 +2392,12 @@ Mutability 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, +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}. +changed via later calls to @code{aset}. Another example: +@code{(symbol-name 'cons)} yields a string @code{"cons"} that should +not be changed. A mutable object stops being mutable if it is part of an expression that is evaluated. For example: @@ -2413,9 +2415,7 @@ Mutability reverse does not occur: an object that should not be changed never becomes mutable afterwards. - Trying to modify a constant variable signals an error -(@pxref{Constant Variables}). -If a program attempts to change other objects that should not be + If a program attempts to change objects that should not be 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 @@ -2424,8 +2424,8 @@ Mutability error if a program attempts to change a constant. Ideally the Emacs Lisp interpreter will evolve in latter direction.} - When the same value appears multiple times in a program, the Lisp -interpreter might save time or space by reusing existing values or + When similar constants occur as parts of a program, the Lisp +interpreter might save time or space by reusing existing constants or their components. For example, @code{(eq "abc" "abc")} returns @code{t} if the interpreter creates only one instance of the string literal @code{"abc"}, and returns @code{nil} if it creates two -- 2.17.1 --------------7E62896F175FD42241D7F338 Content-Type: text/x-patch; charset=UTF-8; name="0001-Don-t-use-constant-for-values-you-shouldn-t-change.patch" Content-Disposition: attachment; filename*0="0001-Don-t-use-constant-for-values-you-shouldn-t-change.patc"; filename*1="h" Content-Transfer-Encoding: quoted-printable >From 1a41838ba32429bb44c0d3ac933d266293f6cb3c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 May 2020 09:27:02 -0700 Subject: [PATCH] =3D?UTF-8?q?Don=3DE2=3D80=3D99t=3D20use=3D20=3DE2=3D80=3D= 9Cconstant?=3D =3D?UTF-8?q?=3DE2=3D80=3D9D=3D20for=3D20values=3D20you=3D20shouldn=3DE2=3D= 80=3D99t=3D20change?=3D MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Inspired by patch proposed by Dmitry Gutov (Bug#40671#393) and by further comments by him and by Michael Heerdegen in the same bug report. * doc/lispintro/emacs-lisp-intro.texi (setcar): Don=E2=80=99t push mutability here. * doc/lispref/eval.texi (Self-Evaluating Forms, Quoting) (Backquote): * doc/lispref/lists.texi (Modifying Lists): * doc/lispref/objects.texi (Lisp Data Types, Mutability): * doc/lispref/sequences.texi (Array Functions, Vectors): * doc/lispref/strings.texi (String Basics, Modifying Strings): Don=E2=80=99t use the word =E2=80=9Cconstant=E2=80=9D to describe all val= ues that a program should not change. * doc/lispref/objects.texi (Mutability): Rename from =E2=80=9CConstants and Mutability=E2=80=9D. All uses changed= . In a footnote, contrast the Emacs behavior with that of Common Lisp, Python, etc. for clarity, and say the goal is to be nicer. --- doc/lispintro/emacs-lisp-intro.texi | 5 +- doc/lispref/elisp.texi | 2 +- doc/lispref/eval.texi | 21 ++++--- doc/lispref/lists.texi | 16 ++--- doc/lispref/objects.texi | 98 +++++++++++++++-------------- doc/lispref/sequences.texi | 25 ++++---- doc/lispref/strings.texi | 11 ++-- 7 files changed, 87 insertions(+), 91 deletions(-) diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-li= sp-intro.texi index ea16d9ef15..46462162ca 100644 --- a/doc/lispintro/emacs-lisp-intro.texi +++ b/doc/lispintro/emacs-lisp-intro.texi @@ -7317,8 +7317,6 @@ setcar works is to experiment. We will start with the @code{setcar} function. =20 @need 1200 -@cindex constant lists -@cindex mutable lists First, we can make a list and then set the value of a variable to the list, using the @code{setq} special form. Because we intend to use @code{setcar} to change the list, this @code{setq} should not use the @@ -7327,8 +7325,7 @@ setcar tried to change part of the program while running it. Generally speaking an Emacs Lisp program's components should be constant (or unchanged) while the program is running. So we instead construct an -animal list that is @dfn{mutable} (or changeable) by using the -@code{list} function, as follows: +animal list by using the @code{list} function, as follows: =20 @smallexample (setq animals (list 'antelope 'giraffe 'lion 'tiger)) diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi index bba1b63115..9a6796790c 100644 --- a/doc/lispref/elisp.texi +++ b/doc/lispref/elisp.texi @@ -297,7 +297,7 @@ Top * Circular Objects:: Read syntax for circular structure. * Type Predicates:: Tests related to types. * Equality Predicates:: Tests of equality between any two objects. -* Constants and Mutability:: Whether an object's value can change. +* Mutability:: Some objects should not be modified. =20 Programming Types =20 diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi index baddce4d9c..39f342a798 100644 --- a/doc/lispref/eval.texi +++ b/doc/lispref/eval.texi @@ -158,11 +158,11 @@ Self-Evaluating Forms @end group @end example =20 - A self-evaluating form yields constant conses, vectors and strings, an= d you -should not attempt to modify their contents via @code{setcar}, @code{ase= t} or + A self-evaluating form yields a value that becomes part of the program= , +and you should not try to modify it via @code{setcar}, @code{aset} or similar operations. The Lisp interpreter might unify the constants yielded by your program's self-evaluating forms, so that these -constants might share structure. @xref{Constants and Mutability}. +constants might share structure. @xref{Mutability}. =20 It is common to write numbers, characters, strings, and even vectors in Lisp code, taking advantage of the fact that they self-evaluate. @@ -564,8 +564,8 @@ Quoting =20 @defspec quote object This special form returns @var{object}, without evaluating it. -The returned value is a constant, and should not be modified. -@xref{Constants and Mutability}. +The returned value might be shared and should not be modified. +@xref{Self-Evaluating Forms}. @end defspec =20 @cindex @samp{'} for quoting @@ -608,9 +608,9 @@ Quoting =20 Although the expressions @code{(list '+ 1 2)} and @code{'(+ 1 2)} both yield lists equal to @code{(+ 1 2)}, the former yields a -freshly-minted mutable list whereas the latter yields a constant list -built from conses that may be shared with other constants. -@xref{Constants and Mutability}. +freshly-minted mutable list whereas the latter yields a list +built from conses that might be shared and should not be modified. +@xref{Self-Evaluating Forms}. =20 Other quoting constructs include @code{function} (@pxref{Anonymous Functions}), which causes an anonymous lambda expression written in Lisp @@ -710,8 +710,9 @@ Backquote @end example =20 If a subexpression of a backquote construct has no substitutions or -splices, it acts like @code{quote} in that it yields constant conses, -vectors and strings that should not be modified. +splices, it acts like @code{quote} in that it yields conses, +vectors and strings that might be shared and should not be modified. +@xref{Self-Evaluating Forms}. =20 @node Eval @section Eval diff --git a/doc/lispref/lists.texi b/doc/lispref/lists.texi index fcaf4386b1..ae793d5e15 100644 --- a/doc/lispref/lists.texi +++ b/doc/lispref/lists.texi @@ -873,8 +873,8 @@ Modifying Lists operations because they change existing list structure. Destructive operations should be applied only to mutable lists, that is, lists constructed via @code{cons}, @code{list} or similar -operations. Lists created by quoting are constants and should not be -changed by destructive operations. @xref{Constants and Mutability}. +operations. Lists created by quoting are part of the program and +should not be changed by destructive operations. @xref{Mutability}. =20 @cindex CL note---@code{rplaca} vs @code{setcar} @quotation @@ -911,7 +911,7 @@ Setcar =20 @example @group -(setq x (list 1 2)) ; @r{Create a mutable list.} +(setq x (list 1 2)) @result{} (1 2) @end group @group @@ -931,7 +931,7 @@ Setcar =20 @example @group -;; @r{Create two mutable lists that are partly shared.} +;; @r{Create two lists that are partly shared.} (setq x1 (list 'a 'b 'c)) @result{} (a b c) (setq x2 (cons 'z (cdr x1))) @@ -1022,11 +1022,11 @@ Setcdr =20 @example @group -(setq x (list 1 2 3)) ; @r{Create a mutable list.} +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group -(setcdr x '(4)) ; @r{Modify the list's tail to be a constant list.} +(setcdr x '(4)) @result{} (4) @end group @group @@ -1135,11 +1135,11 @@ Rearrangement =20 @example @group -(setq x (list 1 2 3)) ; @r{Create a mutable list.} +(setq x (list 1 2 3)) @result{} (1 2 3) @end group @group -(nconc x '(4 5)) ; @r{Modify the list's tail to be a constant list.} +(nconc x '(4 5)) @result{} (1 2 3 4 5) @end group @group diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 1d5b2c690f..136213ad66 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -46,10 +46,6 @@ Lisp Data Types Lisp variables can only take on values of a certain type. @xref{Variables with Restricted Values}.) =20 - Some Lisp objects are @dfn{constant}: their values should never change= . -Others are @dfn{mutable}: their values can be changed via destructive -operations that involve side effects. - This chapter describes the purpose, printed representation, and read syntax of each of the standard types in GNU Emacs Lisp. Details on how to use these types can be found in later chapters. @@ -63,7 +59,7 @@ Lisp Data Types * Circular Objects:: Read syntax for circular structure. * Type Predicates:: Tests related to types. * Equality Predicates:: Tests of equality between any two object= s. -* Constants and Mutability:: Whether an object's value can change. +* Mutability:: Some objects should not be modified. @end menu =20 @node Printed Representation @@ -2379,51 +2375,59 @@ Equality Predicates @end example @end defun =20 -@node Constants and Mutability -@section Constants and Mutability -@cindex constants +@node Mutability +@section Mutability @cindex mutable objects =20 - Some Lisp objects are constant: their values should never change -during a single execution of Emacs running well-behaved Lisp code. -For example, you can create a new integer by calculating one, but you -cannot modify the value of an existing integer. - - Other Lisp objects are mutable: it is safe to change their values -via destructive operations involving side effects. For example, an -existing marker can be changed by moving the marker to point to -somewhere else. - - Although all numbers are constants and all markers are -mutable, some types contain both constant and mutable members. These -types include conses, vectors, strings, and symbols. For example, the s= tring -literal @code{"aaa"} yields a constant string, whereas the function -call @code{(make-string 3 ?a)} yields a mutable string that can be -changed via later calls to @code{aset}. - - A mutable object can become constant if it is part of an expression -that is evaluated. The reverse does not occur: constant objects -should stay constant. - - Trying to modify a constant variable signals an error -(@pxref{Constant Variables}). -A program should not attempt to modify other types of constants because = the -resulting behavior is undefined: the Lisp interpreter might or might -not detect the error, and if it does not detect the error the -interpreter can behave unpredictably thereafter. Another way to put -this is that although mutable objects are safe to change and constant -variables reliably prevent attempts to change them, other constants -are not safely mutable: if a misbehaving program tries to change such a -constant then the constant's value might actually change, or the -program might crash or worse. This problem occurs -with types that have both constant and mutable members, and that have -mutators like @code{setcar} and @code{aset} that are valid on mutable -objects but hazardous on constants. - - When the same constant occurs multiple times in a program, the Lisp + 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, +although you can create a new number by calculating one, Lisp provides +no operation to change the value of an existing number. + + Other Lisp objects are @dfn{mutable}: it is safe to change their +values via destructive operations involving side effects. For +example, an existing marker can be changed by moving the marker to +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. + + A mutable object stops being mutable if it is part of an expression +that is evaluated. For example: + +@example +(let* ((x (list 0.5)) + (y (eval (list 'quote x)))) + (setcar x 1.5) ;; The program should not do this. + y) +@end example + +@noindent +Although the list @code{(0.5)} was mutable when it was created, it shoul= d not +have been changed via @code{setcar} because it given to @code{eval}. Th= e +reverse does not occur: an object that should not be changed never +becomes mutable afterwards. + + If a program attempts to change objects that should not be +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 +JavaScript and Python where an interpreter is required to signal an +error if a program attempts to change a constant. Ideally the Emacs +Lisp interpreter will evolve in latter direction.} + + When similar constants occur as parts of a program, the Lisp interpreter might save time or space by reusing existing constants or -constant components. For example, @code{(eq "abc" "abc")} returns +their components. For example, @code{(eq "abc" "abc")} returns @code{t} if the interpreter creates only one instance of the string -constant @code{"abc"}, and returns @code{nil} if it creates two +literal @code{"abc"}, and returns @code{nil} if it creates two instances. Lisp programs should be written so that they work regardless of whether this optimization is in use. diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi index 1cb0d05cc7..91c3049f87 100644 --- a/doc/lispref/sequences.texi +++ b/doc/lispref/sequences.texi @@ -183,11 +183,11 @@ Sequence Functions =20 @example @group -(setq bar (list 1 2)) ; @r{Create a mutable list.} +(setq bar (list 1 2)) @result{} (1 2) @end group @group -(setq x (vector 'foo bar)) ; @r{Create a mutable vector.} +(setq x (vector 'foo bar)) @result{} [foo (1 2)] @end group @group @@ -278,7 +278,7 @@ Sequence Functions =20 @example @group -(setq x (list 'a 'b 'c)) ; @r{Create a mutable list.} +(setq x (list 'a 'b 'c)) @result{} (a b c) @end group @group @@ -320,7 +320,7 @@ Sequence Functions For the vector, it is even simpler because you don't need setq: =20 @example -(setq x (copy-sequence [1 2 3 4])) ; @r{Create a mutable vector.} +(setq x (copy-sequence [1 2 3 4])) @result{} [1 2 3 4] (nreverse x) @result{} [4 3 2 1] @@ -331,6 +331,7 @@ Sequence Functions Note that unlike @code{reverse}, this function doesn't work with strings= . Although you can alter string data by using @code{aset}, it is strongly encouraged to treat strings as immutable even when they are mutable. +@xref{Mutability}. =20 @end defun =20 @@ -374,7 +375,7 @@ Sequence Functions =20 @example @group -(setq nums (list 1 3 2 6 5 4 0)) ; @r{Create a mutable list.} +(setq nums (list 1 3 2 6 5 4 0)) @result{} (1 3 2 6 5 4 0) @end group @group @@ -1228,7 +1229,7 @@ Array Functions =20 @example @group -(setq w (vector 'foo 'bar 'baz)) ; @r{Create a mutable vector.} +(setq w (vector 'foo 'bar 'baz)) @result{} [foo bar baz] (aset w 0 'fu) @result{} fu @@ -1237,7 +1238,7 @@ Array Functions @end group =20 @group -;; @r{@code{copy-sequence} creates a mutable string.} +;; @r{@code{copy-sequence} copies the string to be modified later.} (setq x (copy-sequence "asdfasfd")) @result{} "asdfasfd" (aset x 3 ?Z) @@ -1247,9 +1248,7 @@ Array Functions @end group @end example =20 -The @var{array} should be mutable; that is, it should not be a constant, -such as the constants created via quoting or via self-evaluating forms. -@xref{Constants and Mutability}. +The @var{array} should be mutable. @xref{Mutability}. =20 If @var{array} is a string and @var{object} is not a character, a @code{wrong-type-argument} error results. The function converts a @@ -1262,7 +1261,6 @@ Array Functions =20 @example @group -;; @r{Create a mutable vector and then fill it with zeros.} (setq a (copy-sequence [a b c d e f g])) @result{} [a b c d e f g] (fillarray a 0) @@ -1271,7 +1269,6 @@ Array Functions @result{} [0 0 0 0 0 0 0] @end group @group -;; @r{Create a mutable string and then fill it with "-".} (setq s (copy-sequence "When in the course")) @result{} "When in the course" (fillarray s ?-) @@ -1310,8 +1307,8 @@ Vectors evaluation: the result of evaluating it is the same vector. This does not evaluate or even examine the elements of the vector. @xref{Self-Evaluating Forms}. Vectors written with square brackets -are constants and should not be modified via @code{aset} or other -destructive operations. @xref{Constants and Mutability}. +should not be modified via @code{aset} or other destructive +operations. @xref{Mutability}. =20 Here are examples illustrating these principles: =20 diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi index a4c9c2549c..70c3b3cf4b 100644 --- a/doc/lispref/strings.texi +++ b/doc/lispref/strings.texi @@ -49,10 +49,9 @@ String Basics =20 Since strings are arrays, and therefore sequences as well, you can operate on them with the general array and sequence functions documented -in @ref{Sequences Arrays Vectors}. For example, you can access or -change individual characters in a string using the functions @code{aref} -and @code{aset} (@pxref{Array Functions}). However, you should not -try to change the contents of constant strings (@pxref{Modifying Strings= }). +in @ref{Sequences Arrays Vectors}. For example, you can access +individual characters in a string using the function @code{aref} +(@pxref{Array Functions}). =20 There are two text representations for non-@acronym{ASCII} characters in Emacs strings (and in buffers): unibyte and multibyte. @@ -382,9 +381,7 @@ Modifying Strings @cindex string modification =20 You can alter the contents of a mutable string via operations -described in this section. However, you should not try to use these -operations to alter the contents of a constant string. -@xref{Constants and Mutability}. +described in this section. @xref{Mutability}. =20 The most basic way to alter the contents of an existing string is with @code{aset} (@pxref{Array Functions}). @code{(aset @var{string} --=20 2.17.1 --------------7E62896F175FD42241D7F338-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 01:56: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 To: Drew Adams , Michael Heerdegen , Paul Eggert Cc: ke.vigouroux@laposte.net, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158916210612618 (code B ref 40671); Mon, 11 May 2020 01:56:02 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 01:55:06 +0000 Received: from localhost ([127.0.0.1]:50797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxes-0003HQ-6f for submit@debbugs.gnu.org; Sun, 10 May 2020 21:55:06 -0400 Received: from mail-wm1-f42.google.com ([209.85.128.42]:55925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxeq-0003Gh-If for 40671@debbugs.gnu.org; Sun, 10 May 2020 21:55:05 -0400 Received: by mail-wm1-f42.google.com with SMTP id e26so16340951wmk.5 for <40671@debbugs.gnu.org>; Sun, 10 May 2020 18:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ar+Te5jpkOyOIJ17yK7AZ+kW09JoU4YL66D5CMZtzzM=; b=NodDYvv7C7GjZvE2zFn6advyMOGcTOKL6Hz3rjKiYyVPUB+c4Xe/orYHMnwidTQpw8 QO9KuraMKLodDsHgLmpsNthq0/+mn9hkZ+N+nHV/V7zLkSXcQObchZ5Ywye55Y+xp+LE ZrwJPe3/HCCj8ON0AjMdH3y4oUgA0WdSgFcjAtFAoCVUTILYUzb+6s4tMuS2QV2qTxTw gU9hoMgeb35tXP3r08MSN7oCAl0Ha3ocov/pO27v2JpYD4CD52HqYOTYMBEAGXWKqMqt JyV89fvEPY4PsdsLyyQ1HZCzEXCKvXFRivAS6MhrufKHJ9fOOxnBUKU9l1r9qf8VU5w0 3Cmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ar+Te5jpkOyOIJ17yK7AZ+kW09JoU4YL66D5CMZtzzM=; b=jmUl3rMkh+7Pyl46nwfactJ9uWaYtBGhIYeWvg1aOV7XlhXv29xANcwQi7cA2GIKjd Q+6e5X0pK3yDcmt0Xs/ZxHhoOMUMMMqjnlgTxSR7SXwdKfg1ENqxekrNNLUM0nXgofBN 0+kdXbmHN+lvq9DQ9xgzY3ORguAQF8RDcdJg7Udkv79p1NlNXlVDnavZ7NPfNLOheNlx BXzqxUXUif5BnBZ+vFo04yXkuIRAs0SF3H3KXscFcd91//e6pLK1/LbZTrUxRaTotH0X NxMBtPsXpMihlTYvmAKokKALZ/ONdsLKGgEyeePgdYmcdG0jZmQuVR+r+vrDb+gAZVEE esCw== X-Gm-Message-State: AGi0PubkiL/925T+hvTa5Ebgj1TN6htSJuA5U8fWfdVefA8r5ZnwUWEd 1F3vtfXQICvIhaP29We0oGA= X-Google-Smtp-Source: APiQypLDaVzcQ8G98pYBHFVUdZYyIjx2WPfFBcN7ZAbaXbCfOJsz8WPLMbLq1nf3M7JZ1JpdI0B4iA== X-Received: by 2002:a1c:9804:: with SMTP id a4mr4644300wme.80.1589162098278; Sun, 10 May 2020 18:54:58 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id h74sm16238936wrh.76.2020.05.10.18.54.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 18:54:57 -0700 (PDT) References: <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> <87mu6ftk6o.fsf@web.de> From: Dmitry Gutov Message-ID: <0020c4e0-a669-934f-f277-a34b0fd28a65@yandex.ru> Date: Mon, 11 May 2020 04:54:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 11.05.2020 04:47, Drew Adams wrote: >> Drew >> mentioned his dislike for the term "safe" AFAIR > I don't recall saying that, but I may have. Not > sure what's meant here. I objected to using > "dangerous", as if the gotcha was generally > hazardous to life. Would "unsafe mutations" be better? From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 01:58: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 To: Dmitry Gutov Cc: ke.vigouroux@laposte.net, Richard Stallman , Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158916222812893 (code B ref 40671); Mon, 11 May 2020 01:58:01 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 01:57:08 +0000 Received: from localhost ([127.0.0.1]:50802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxgq-0003Lr-IY for submit@debbugs.gnu.org; Sun, 10 May 2020 21:57:08 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXxgp-0003LY-FJ for 40671@debbugs.gnu.org; Sun, 10 May 2020 21:57:07 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0E1A01600C7; Sun, 10 May 2020 18:57:02 -0700 (PDT) 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 Wh_S_3-Y8ls1; Sun, 10 May 2020 18:57:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 39C3D1600CD; Sun, 10 May 2020 18:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 bdnCwAKv-bQJ; Sun, 10 May 2020 18:57:01 -0700 (PDT) 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 E8D081600C7; Sun, 10 May 2020 18:57:00 -0700 (PDT) References: <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> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <4ba236ce-ade0-5cd1-656a-f2df46d67d5f@cs.ucla.edu> Date: Sun, 10 May 2020 18:57:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/10/20 5:44 PM, Dmitry Gutov wrote: > "Indeed"? Indeed yes. :-) > The changing "mutability" status is imaginary, however. It's part of a spec. Not every constraint in a spec needs to be enforced directly by the implementation. That doesn't mean these constraints are "= imaginary". > This also requires the reader to read the manual without missing a refe= rence. A > regular person would not understand your meaning of "mutable" without f= ollowing > the reference to {Mutability}. If a paragraph says "mutable" and has a cross-reference to the "Mutabilit= y" section, that's good enough. This is a reference manual, not a tutorial, = and we can assume a reasonable level of competence on the part of the reader. > Does is ignore the possibility of the example in the previous version, = then? I don't understand this remark. > I'm trying to point out the incompatibility with the regular meanings o= f the > words used. >> Because it's not an accurate statement of the problem. The set of obje= cts that >> might be shared differs from the set of objects that should not change= . The >> Mutability node focuses on the latter set of objects, and gives the fo= rmer as an >> example but it is not the only sort of object that should not change. >=20 > But if we don't mention such cases in "Mutability", where do we cover t= hem? Fair enough. I added an example of such a case to "Mutability" in the pro= posal in my most-recent email (Bug#40671#441). > +(let* ((x (list 0.5)) > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (y (eval (list 'quote x)))) > +=C2=A0 (setcar x 1.5) ;; The program should not do this. > +=C2=A0 y) >=20 > Why is this a problem? Do we expect this it could lead to a segfault? Probably not a segfault in the current implementation, but the behavior i= sn't defined. And we don't want the behavior to be defined, as that would proh= ibit some optimizations that may be coming down the road. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 02:35: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 To: Dmitry Gutov , Michael Heerdegen , Paul Eggert Cc: ke.vigouroux@laposte.net, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158916446717510 (code B ref 40671); Mon, 11 May 2020 02:35:01 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 02:34:27 +0000 Received: from localhost ([127.0.0.1]:50829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXyGi-0004Xu-6T for submit@debbugs.gnu.org; Sun, 10 May 2020 22:34:27 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:48078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXyGg-0004Xc-EH for 40671@debbugs.gnu.org; Sun, 10 May 2020 22:34:11 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04B2X2xP007188; Mon, 11 May 2020 02:33:51 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=C2cn6ZF6QPWf4Sg0nvZ6ax8eWLausmKonVAxOt6w+kA=; b=ipGBIPubn0pkI47d+kNKeM97d6qdSdeJaaLcVOkT+k8E+cd6xkxRWhyeQnay7mLd8Txt amLzBP9HEtckHRlyRiaDa0OehdAQOZFDlluw4Fbyq7xLWwLrcM+hKIuGro+fgewkXKfK 1DtVLSIqiTGueZooJfuIxifV63u9XQc4769PLvN4tOi36AmxjP0TXPFmR526zpCN258O nBeZ3kCkmHK0cj7wLnwL/kBPuoLz0oq9JWX/G25MEODNDXYbiRGM2E5Y3eeGR30ySFc6 eXo2ka9ILJo6FADwaT57JABKM/ej7D16nv1o4OfVPnmsG8c2kes1h7Giy1taAxHVpPXH kQ== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 30x3gmagaj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 11 May 2020 02:33:51 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04B2RnFa063394; Mon, 11 May 2020 02:33:50 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 30xbgcc6wa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 May 2020 02:33:50 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 04B2XfcF013203; Mon, 11 May 2020 02:33:42 GMT MIME-Version: 1.0 Message-ID: <19c29f91-b8d6-40bf-a3ee-42d8d84a1013@default> Date: Sun, 10 May 2020 19:33:40 -0700 (PDT) From: Drew Adams References: <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> <87mu6ftk6o.fsf@web.de> <0020c4e0-a669-934f-f277-a34b0fd28a65@yandex.ru> In-Reply-To: <0020c4e0-a669-934f-f277-a34b0fd28a65@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 spamscore=0 suspectscore=18 phishscore=0 bulkscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110015 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 clxscore=1015 spamscore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 suspectscore=18 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110016 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > >> Drew mentioned his dislike for the term "safe" AFAIR > > > > I don't recall saying that, but I may have. Not > > sure what's meant here. I objected to using > > "dangerous", as if the gotcha was generally > > hazardous to life. >=20 > Would "unsafe mutations" be better? I didn't really want to get into this with you guys. I just wanted to reply to Michael's message. But... I'd prefer that we speak of "modification", not "mutation". "Mutation" has a connotation of something happening on its own. If that were the case then we wouldn't be trying to tell people not to do something! I'm not a big fan of "safe" (or, especially, "dangerous"), unless it's about human safety (e.g. an airline maintenance manual). I'd prefer that we just tell users that if they do certain things then the behavior of their code _might not be what they expect_. Or that the behavior is "undefined". And let it go at that. What's important is to give them some idea of _what_ it is that we're telling them not to do. I don't have an example, but I think a simple quoted-list example can get the point across. And then you can say something about strings or whatever, if you like, without bothering with more examples. My advice: don't try to explain too well just what happens. See if you can get the general point across without any exhaustive rundown of a bunch of different cases or trying to be too exact. If a user understands that internal Lisp structures (objects) can get created by (1) the Lisp reader, (2) the interpreter, and (3) the byte compiler, and if s?he understands that what's seen in the source code does not necessarily correspond to when a corresponding Lisp object gets created, then s?he'll get it. Just when, and how many times does the source code of a quoted list result in a new cons? You can't really know. When it's read? byte-compiled? A new Lisp user thinks in terms of interpreted source code. Seeing a quoted list, s?he thinks that a new cons is created each time it's read, interpreted, or byte-compiled. But that may not (typically does not) happen. If you modify the cons that resulted from a source-code quoted list then that _same_ cons might be baked into the internal code thereafter. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 02:57: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 To: Drew Adams Cc: ke.vigouroux@laposte.net, Paul Eggert , 40671@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158916581820014 (code B ref 40671); Mon, 11 May 2020 02:57:02 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 02:56:58 +0000 Received: from localhost ([127.0.0.1]:50864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXycj-0005Cj-Of for submit@debbugs.gnu.org; Sun, 10 May 2020 22:56:57 -0400 Received: from mout.web.de ([212.227.15.3]:57451) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXych-0005CU-Je for 40671@debbugs.gnu.org; Sun, 10 May 2020 22:56:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1589165778; bh=CCJEZG2HV0vlWeQIF0G3pfsEQu/RA7FLfWaQO71o7gA=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=bSO9OR0M6F+7KfVPTbFbVuCH7RxA6U4Ca9dtLQVFqBrqDdtX8/KwBkOwScsYAs90A RQX67MY+vECgQUEYETPVHtV6xj4d33AjfsCbpkTB7w7/XhjdynoozlLAiP9hdRy4K9 0rWMy7SXnJY1HbzUP3LGTIWi/0MBN8ADIZKpK6y8= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.107.170]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MALeR-1jNl5F1yY7-00BvD0; Mon, 11 May 2020 04:56:18 +0200 From: Michael Heerdegen References: <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> <87mu6ftk6o.fsf@web.de> Date: Mon, 11 May 2020 04:56:16 +0200 In-Reply-To: (Drew Adams's message of "Sun, 10 May 2020 18:47:25 -0700 (PDT)") Message-ID: <873687xjqn.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:eZOIGFvsg2qRV5ATndaL9Fm12zJh7p9SvkGQHPlfYRKva3AWrHV 5xoVbDzJeqonjpiflYEra2CvPqJm8SvhWV0QENOVTeghQHeOJhyPjNAcFenqfloBkXN1nTy bIOkY+UCqklp0dsSZmx5AMfEoUBhQiH91dPpiBP7HRyLXfxIIy0dwU7W6NGyoO8vg+a5b9h 6RAQ1KB8JLtyqWRs+lZow== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ZMndmYeP/lA=:uHHPDqXqukj0yJ0IPAz1fT UUNGfIA/ZiCHyD9fce5JczsBBClX9nRJg9Hc7hY1W/JPOLLiVeOW7sxNHUG6rJrCiTY68QrWa Aa+tNWhZdUUpzfnTgJKbScopWWjF2BrybSC2HPK8u7Xh2RxyxM1m+PkrF8u0zYHxVypMWZoO3 F4pqjtMYJs/9fIRk7XNSaOCn1bfmILvy5R72B6KXyEb/9a1c5p137CI5z6YFfzqKihkxhXS6/ kra13BT8+bhGxVClwgI4Iqwzf0kE5BZzDCbqQ8VUKX23/DHBbGhBfGTohNFIiAxZGoR963sBO E+60qSd5PAcwaY7jU2JQa4UPuVkuWXWKmMWJM4UM+SUr8ODU03GWzpCYlD4xlWu4gP1BbIxTb 2FvtCQlMca1wiId2on62xkKdrNuHfCiiUIM4UGtIuSn9XFnvCdurWbjoxE4XKwIquAowjCxyZ p4/y2xtWTa3De438w+T7ZE+qt7O66gBn0xlPK33h/VT/j2u+xzAeazle4IcZR49QH+IDOI90h fLMZ1ptepISCB8JVvuYwR05lnTS/MmXXZWniAawmhI3jpANp4+6RjrIT7dlEwzqzL0c2fHx4O DFQRiI2a7fh9YF0rB2xd7II73riubUcHHiopeQ7SXapSum72AvuWIzEsv4N4O4K1ukwolJcdt 4PYqYYgTqGsys99JSqd41jZokUz5GH7sq8bSKRXXrWahJsSOgsU/iZ0VMqKSMgDdadSRU5r8W RUdllL6R4Y9f/MCMqsOdtEg1STFUMrDKIi90KVA0iTAj5hXPLLv+zW9ErD6rDdc7RprJv4juL H4EFJKS7tuDPv74WTyb0Dt7r/HIiVY9S6ti1VgGp5NBau85urHK1Eccfd+YgPOus9+HwLaHa4 ByT+3JF7I6C7zbf0nmAxP6JWdZ1BLqnAPv8VDfGVkykyKjhiJDUmR3nQZL+PNUX6fLo60r/Iw xGmsWJy+ZM/3qwvPWSyhg766oTbScKJaCY501ouUm32o6Wl7OWyEEFBD8GIwMaAhnBVqskXx0 ZmPlADS3QWxiQFCTuNIB7ggDKeCWPnwd0gDGgGzvYLnQEi2SQ/vv6rk6yreknBWic6Rkz4ScJ WRoiavcTNamWEqlwxix5LyojIJxt66FIfbaxcXQ9iJ/K8CkocsKnrAmW0zPZ+4ad/TtatKWgN dlmqpW4pQCYxfUGQNjaEtNub+3GaLW4LXxPBMOKLt0HSR2empqA3+YvedwId8lRcdI1QB0MlA YOBA3i7TV6rOX+cJb X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > But are symbols otherwise constant, besides their > values? Depends what you mean by "symbol", perhaps. > Certainly you can change not only `symbol-value' but > also `symbol-function' and `symbol-plist'. I don't > see symbols as very constant. Also makes sense, yes. > I think that text wasn't too bad, but I see your point. > > And it's especially not good to use "value" in the two > different senses, as (1) something you see ("appears") > in a source program and (2) a runtime value that results > from reading, byte-compiling, or interpreting that source > code. > > Maybe "object" or "Lisp object" instead of "value", for > #2? The term "value" is used all over the place in the manual for #2, so people are familiar with it, we need a better term for (1) instead I think. (info "(elisp) Equality Predicates") already uses the term "literal object" btw: The Emacs Lisp byte compiler may collapse identical literal objects, such as literal strings, into references to the same object, with the effect that the byte-compiled code will compare such objects as =E2=80=98eq=E2=80=99, while the interpreted version of= the same code will not. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 03:19: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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Dmitry Gutov Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158916712422312 (code B ref 40671); Mon, 11 May 2020 03:19:02 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 03:18:44 +0000 Received: from localhost ([127.0.0.1]:50881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXyxo-0005nn-6j for submit@debbugs.gnu.org; Sun, 10 May 2020 23:18:44 -0400 Received: from mout.web.de ([212.227.15.14]:46491) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXyxm-0005nR-3s for 40671@debbugs.gnu.org; Sun, 10 May 2020 23:18:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1589167094; bh=MkMVe6bRZco1G7GLjwRj+5e1LA9NbiSgrGlAHNFPeqY=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=i6nyI453N7ZyqJpGMOSJ6cPVCgGXfY0fcXz2coDWS9+ibmP1VbmN2W1vh0+P7R5Pg Y+jgVEHnJSFHi6WCURYakteEJSmbQTv2radGjRDOJRJHM7xFNHpIy+piUMe93X6GmL SIexIJ5XoMUfR/TB07VfyEkYHO/mJBYubDUCb78I= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.107.170]) by smtp.web.de (mrweb004 [213.165.67.108]) with ESMTPSA (Nemesis) id 0LxqwW-1j48Hq2RN6-015MrE; Mon, 11 May 2020 05:18:14 +0200 From: Michael Heerdegen References: <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> <87mu6ftk6o.fsf@web.de> <81f50f04-b5f8-12de-9171-f9660801c5ab@cs.ucla.edu> Date: Mon, 11 May 2020 05:18:13 +0200 In-Reply-To: <81f50f04-b5f8-12de-9171-f9660801c5ab@cs.ucla.edu> (Paul Eggert's message of "Sun, 10 May 2020 18:53:05 -0700") Message-ID: <87y2pzw45m.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:nkvG7sH9YnubwhzCAggxzmVwjNHphTX4PrxqQTEuiVfYOwpX3bA zZc65pK6CtvIcpBUm9nHMTpTlJK3lwFqUmY56PPLvqcet03qr20GVAuFW9gD9unPi36JXAO tslHOw8/KLRQq7bxQ02KxBiMkRrY/iG+NsXqtW82I7SwBxcvp4o46FBb6o5p3W9bthsA6lj hrN8SFyXy97p9fSMsOrtA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:SodzdJhiWNU=:2+CrPIlwUyZ2k+psEyAPhZ kyQrI69cOxQXPr0qTqYbU+PiWGXPIRDYXB1iUzXrHfnNxazWafbDTs2Kl1ouuOp44Td104Snh t6bjsScSsMZnNBDmGXum3AZa4e6b4Akiuhs0Yb/aY3h72CvkSnwZiisDK0oi6EOd57CRo4DmL PdE4kLu2JUzqfpCf3MRhfsb0xoCGfLvk+9c5jtoCgcNqUNQ3Ei6wrGwj4ixgEBIL4Uc/bEF6f F5qmrEu4P2Bv2XayLlt7EWYKQbNSMsfes+3AOllsFM9KH2c5KLEYwC9FwAuM9Ou96zYlAM8DA nVqIXqyEJhTx+srrlxNx5/h8wlshPaaFOVLSwyp2znbNXS4KvNZACcwtx/8FleHEaLsK4jQ58 CQyBO0t/7vpx2EsOjsg84u4BbJlFugH8nLXA3uxw3Ij70NzQcRpqP2wWMN2AwLliLUwKAVhay OeEo/fVPzd9YpSP6669C4z0M3ruxp1cT9ls52uiICcNjqkL62r8XLOiskfK6AVkbTwkKSGsFM g+LjbvNdFLJq1MvX/WA/tvXj05L/noLy2VIHjZEXXSIodfWj0/CvDfhmWDxop1fZdCSnKhFNG mlT+NvRLfaNmDEJZispYFimG8NX2whRyDfEaxtVcEzmcpVvf+4YMBWevG23fyeNni2psh1gYC VJv3eCsO7WmQRBKBe6j7N1P3CW9SOTfqhl2UVoonyTVEADa0WYoATjJbEvr16MmTvFzzkcllB ZCVaCEa8f6Ril/Oxcl75YQVXcnUbw6PS/x92cU84EE0lkZ4XmOHheD3k7AFvHrhVCM25wUX9k hPaNV9l7474yxWK/h0c50HQ+59pKViZukWVNsYlXuldZHnwmyFv4KTIg5sZ+DT/RxnTDml6hE F0vGnf/fk73GbZDbUiM2kJEw+gOxQ8C5Z1RXRKYcSe/VcPe4UG6o8LSoR51iRSmjmi1XR3x5f JqG0kcpDclmz3xkWtmdnpd43hCVznPIR5yV1KyASzbHPmVVHan502QMEdhlPFVst3pNHOWYex ex4unXp/26RH6sf9PgEN9qjYC9AMGZ85KAJHQg/E6Jn1fpSMmBMyjEwOtzHPFMKOnUor1PyFR kuTqC7O2vs0KaoB5N1aeWd7kBPIh62nH9hQf9mx3d6YRzDJUALyGugEOkq1RvgNhnCcYBg/Ns aUAqptL1cn+WGMwnYIhoeSw3mJ1l28OqSI9lhC07IGP3MVfN4Zw5+23zjKriGaL2xP6jEavR8 Xqtxyv2r5tEktnSvv Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > All good points. The simplest fix is to not mention symbol bindings > here, as they're a complicated topic. Yes, agreed. > >> + 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). > > They can if one feeds the values into 'eval', which runs part of a > program. And 'read' can read programs. So I'm not sure I get the > distinction. Now I get how you meant this. I read the sentence more with a written program and syntax in mind. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 04:22: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 To: Michael Heerdegen Cc: ke.vigouroux@laposte.net, Paul Eggert , 40671@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158917089330117 (code B ref 40671); Mon, 11 May 2020 04:22:02 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 04:21:33 +0000 Received: from localhost ([127.0.0.1]:50910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXzwb-0007pg-FW for submit@debbugs.gnu.org; Mon, 11 May 2020 00:21:33 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:55620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXzwY-0007pN-Rs for 40671@debbugs.gnu.org; Mon, 11 May 2020 00:21:31 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04B4Dfwi052433; Mon, 11 May 2020 04:21:22 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=EhcwSjv23tqBtjhGHl+wMA87AjuGJ9PF0jVGmaeTPig=; b=UfHXXYY+KIjS4OVUc6PbOJwG2/dMbZs0iuHQdM+OySqRjza0YtTZRYjsxAOm0fBaP7JH Ij80QOwZZCJpZvnx1NqCvXOncg5rLH8WAsj1HmpfijfwHZCpDOZcffbAmZRaFxnvUBeP agiQ4FxFI2AMaZjntXAJzljZChEp7kAH0fCKs5w0SNXy+EG0Ji6aA2BKxYLBVABt51qu 6Az+rn/HIWrHJjURSUW4SEKIChiiZ1/j1dl+ZaO7GVdpk4NqrMSke0BTRsU4fjuzDw3P lSMo0uLGKkPB94anrdInuCzzqTOmOTRFlZfDeXezEzPQktTWUxgtiG7iWFzPsRJDE27E 3w== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 30x3mbjqda-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 11 May 2020 04:21:22 +0000 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 04B4JTfm070230; Mon, 11 May 2020 04:21:21 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 30x63kuttq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 May 2020 04:21:21 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 04B4LHdG014971; Mon, 11 May 2020 04:21:17 GMT MIME-Version: 1.0 Message-ID: <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> Date: Sun, 10 May 2020 21:21:16 -0700 (PDT) From: Drew Adams References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> In-Reply-To: <873687xjqn.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 suspectscore=18 malwarescore=0 phishscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110033 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 impostorscore=0 mlxscore=0 suspectscore=18 bulkscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110032 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) (This ended up long and a bit off-topic; sorry. Hope it still helps.) > > And it's especially not good to use "value" in the two > > different senses, as (1) something you see ("appears") > > in a source program and (2) a runtime value that results > > from reading, byte-compiling, or interpreting that source > > code. > > > > Maybe "object" or "Lisp object" instead of "value", for > > #2? >=20 > The term "value" is used all over the place in the manual for #2, so > people are familiar with it, we need a better term for (1) instead I > think. (info "(elisp) Equality Predicates") already uses the term > "literal object" btw: >=20 > The Emacs Lisp byte compiler may collapse identical literal > objects, such as literal strings, into references to the same > object, with the effect that the byte-compiled code will compare > such objects as =E2=80=98eq=E2=80=99, while the interpreted version = of the same > code will not. BTW, that node does NOT already contain that text. That paragraph is new for Emacs 27, which is not yet released. IOW, that text is _proposed_ for Emacs 27. But OK. That describes the problem as being about "literal objects". That's essentially the message we're discussing, I think, but it should be broadened beyond just the byte-compiler, I think. Where, if anywhere, does the manual define or describe "literal objects"? I don't think we want to be doing that, unless it's done carefully. For the message we're talking about, I'd say start by talking about source code: forms, sexps. Yes, the sexps that are problematic are, I suppose, what that text calls "literal objects". But I don't see that term defined anywhere. And it seems odd to me to talk about source-code thingies as "objects". Maybe the result of reading, or the result of some initial stage of byte-compiling or interpreting, is a "literal object", but is a source-code sexp a "literal object"? A "literal string" makes sense to me, as a string in source code ("..."). But "literal object" doesn't sound like a source-code thing. Perhaps that's what literal numbers, strings, etc. in source code are called now - "objects"? Sounds odd to me. Checking `i literal' in the Emacs 27 manual, I see no "literal object", but I do see "literal evaluation" and "literal in rx", where "literal" is used as a noun (in both cases presumably). However, the former index entry takes you to node `Self-Evaluating Forms', which never once uses the word "literal" (as adjective or noun) - it talks only about "forms", i.e., source code. That text looks OK. The index item seems wrong - you never get any text that tells you anything about "literal evaluation". This node, and index entry "literal evaluation" are in Emacs 26 (and probably earlier). [Index entry "literal in rx" takes you to node `Rx Constructs', where you find `(literal EXPR)', which is about matching a "literal string". To me, "literal string" is clear enough, and I think of it as both a source-code thing (text) and as a Lisp object (after reading the text, for example). This node is new for Emacs 27.] Searching the Emacs 27 Elisp manual for "literal" I see that there is another occurrence of "literal object", also in a node that is new for release 27, `pcase Macro'. There too the term "literal object"is totally unexplained: "Matches if EXPL equals the literal object. This is a special case of =E2=80=98'VAL=E2=80=99, above, possible because literal objects of these types are self-quoting." (The "possible because..." is not correct English, and I don't know what it's trying to say. Maybe "possibly because..." was meant. Or maybe what was meant was to end a sentence after "above" and start a new sentence with "This is possible because...".) And again, in another new-to-Emacs-27 node, `Backquote Patterns', I see "literal object": "Matches if the corresponding element of EXPVAL is =E2=80=98equal=E2=80=99 to the specified literal object." And again, the term is totally unexplained. (That node also has "literal symbol", which, like "literal string" doesn't shock me. It is "literal object" that I find odd.) Both Emacs 27 and 26, node `Mode-Specific Indent', mention "a literal value (usually zero)". That's OK, I guess, but I think it's untrue. I think what's meant is just "a number (usually zero)". There's nothing literal about it. Node `Rx Constructs' of Emacs 27 introduces "Literals" (noun) as forms (source-code sexps), and shows that they can be strings or chars. I don't have a problem with that. Node `Rx Functions' says "if `literal' or `regexp' forms are used", and I guess that's referring to the forms `(literal...)' and `(regexp...)' introduced in node `Rx Constructs'. And it refers to "string literals". All of that's OK. Node `Extending Rx' mentions "a list literal". Again, like string literal, char literal, etc., this isn't introduced anywhere that I can see, but that's OK - use of "literal" as a noun in such cases clearly means the same as "literal string" etc. Node `Module Initialization' is another new one for Emacs 27, and another place where "literal" is used as a noun: "number literal". Again, no problem for me with that (like "string literal"). All other occurrences of "literal" in the manual are about literal chars, finding a file literally,=20 displaying or matching text literally, or replacing literal text. No problem there, and nothing new there. In sum, "literal object" is nowhere defined, described, or explained. And "object" sounds wrong, to me, when referring to source-code text. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 04:53: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 To: Drew Adams Cc: ke.vigouroux@laposte.net, Paul Eggert , 40671@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15891727421539 (code B ref 40671); Mon, 11 May 2020 04:53:01 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 04:52:22 +0000 Received: from localhost ([127.0.0.1]:50944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY0QQ-0000Ok-8Z for submit@debbugs.gnu.org; Mon, 11 May 2020 00:52:22 -0400 Received: from mout.web.de ([212.227.17.11]:49975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY0QO-0000OW-21 for 40671@debbugs.gnu.org; Mon, 11 May 2020 00:52:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1589172711; bh=K6Obm2ZFhcaHk6PI03Ti949I3dUoZKBsdWB7ExGL9cI=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=iJxoRM3NdeE2J+n5xSjrUuKQDymVMMoFgfU9KRKFyDs4drH0svO4Al19Aatz0iNbY 1sW6gaeMNrYoJRuBAVlkRes9P3/uShpD5BDpJaq9tb5N+gHzPp8beh9Nj2K3GIozxU /M0/XbxvwniAW33bOjNkNRkkLr8Y9KOOaog3Smak= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.107.170]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MeSOZ-1jkqAy2xAN-00QEho; Mon, 11 May 2020 06:51:51 +0200 From: Michael Heerdegen References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> Date: Mon, 11 May 2020 06:51:49 +0200 In-Reply-To: <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> (Drew Adams's message of "Sun, 10 May 2020 21:21:16 -0700 (PDT)") Message-ID: <87tv0nvztm.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:AJj9sq0VkwkQDQKjcgfkW/xDee5iiSV8nWLKFUrdnD6wf9n/Gbp 15SM8qvJcLdETgA90Mi62gduE7xbRAUJ5e1FItoN56rsO2C6dno/GA5sgeRJoeMTe0nuth0 bABdtQZ2Jx5c+vSvrqdOszpyD4j719i+ImQ1VZo+VPeVAjCEM3NzozwPGKBX2mZyJp9wabx hCFGVi/wx+ifqHuFaMx3Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Hn0smEVlv54=:IKL8gM+q3V35QRAsvECZv2 F3OdW9o+NiOFUNAGf3Ts+fQ7PSICQZrmo55Se33oxV9GCh/tKhYI+QGHX0Lhw3oyfPkrLsVoG DLF6E54I7AvyEzpVjRJ8mSQMH/mnHfRLD8AmVPQk8YXCebF6brT1iexz+sMAkELE8w+xAE6/a 1L1mqwNr5lhWprLHmt3M1uLPDJ4YLN3vCysQXMFW7tyPxHu2VNDmOWL1QCtV9YRk4T4WS79zK PiLKrCj5h4LPpVK8EPxOptrSSTrIbZpTXzioCyLBBgWn2Pgi5cd6lGPxc1kMuk7U2x0DxWOhx OEoPUOmALO9Wppnxt4P2coOAjHKSLM7xXwdAJqCTgwfRPAvAghn2ZFiyVehJzKzBF7OB2lce/ oIqOAWR7LGvE6Eu1+5NA6KqJOi8irnA3iHnAPbYDfnG8HKxbnzguDxG8RYMcDWRL1VEdFj8M+ jcd58DSKltsWX2HGuyWo4POUb1+scdyKtW5gXck2ekxqLroIbU7cqjjYYB5XmbgQIcTng/Qql 1XmFp++9bX3s8I+aMqmI5FeWH6QigHDTCotIRfGNVuBzzQ/Lqc1Y8yIam/N3I8/LDsQ8cxjw2 PBUa/uETQ/CsKI+JxjoTtmrLdf05pZyAZSjbYf5RFKtWcuTrLD15rpvr62wL1KWfvUSArgrsY x0YSmQF8cUxPwtc+Fh9GDNnOFJ3OyYNAZ61fG2oy+G1GpAlqEyQI6vrKDiDOjM9CuoKVM7+SF 4aERu5p7npHOBCWg3/ps1/fb/YhXZpO+Mq5ROq87+RJ2snfcG5COLNXhhjuhhFWPa2MqCObDK QOEOk+o5/zjyLIAabPXPaeFZ+oOhMObENjxnEMBbhhklaVjydY/bnWeMEj/5XDNJRYT0A7Ldn plmPhU3+al2hiNMu+ti6MrSJoX+mdOYOL7l/MMkS4f9Ams6yyGDFNTNKwXM5iW7xu4na36N3Z KwL4HmJb3pb/LkOzsVkiUjKXJLxil5dXG/hND2lf2OAH0ifHWrskWfg0wEkhxPOpPH+sVQ8Ts Rmb9gmdAA69SXDoGCSHDnaho4oKfOlCa3lEBWEt5zp5RAebhpyl9sTPDkZjgnDwOSPLqL4Ccr mJHZMGix65pKWibMK4MTUX/NBh8GsVO/0WVQpga7VqzVJWjiz+7UjiEFuXk/uLbrAz/V2eBEv YU1N1JbK1nk48NStdHUYRm8fQqhzSqKLBqn7SvYKNVFB6Nn3Hjw7zdotyF92yilQA2eodsOnv IoJ9vq64ESGV2YdFT X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > In sum, "literal object" is nowhere defined, > described, or explained. And "object" sounds > wrong, to me, when referring to source-code text. Yes, it's vague. Maybe the place I cited should formulated otherwise, since we didn't use the term for the "no no" objects, for reasons. BTW (also @Paul) there are some places (five or so) in Elisp source files that look like (nconc '(x y z) (get-some-list)) Should they be rewritten? Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 06: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 To: Michael Heerdegen , Drew Adams Cc: ke.vigouroux@laposte.net, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, Richard Stallman , Dmitry Gutov Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158917851314019 (code B ref 40671); Mon, 11 May 2020 06:29:01 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 06:28:33 +0000 Received: from localhost ([127.0.0.1]:51030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY1vU-0003e2-Lu for submit@debbugs.gnu.org; Mon, 11 May 2020 02:28:33 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60574) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY1vS-0003dj-Te for 40671@debbugs.gnu.org; Mon, 11 May 2020 02:28:31 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 446C71600AF; Sun, 10 May 2020 23:28:25 -0700 (PDT) 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 NuzvxrqnwKDF; Sun, 10 May 2020 23:28:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 262C21600C7; Sun, 10 May 2020 23:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 hNkPJq4N89Ia; Sun, 10 May 2020 23:28:24 -0700 (PDT) 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 D13231600AF; Sun, 10 May 2020 23:28:23 -0700 (PDT) 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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Sun, 10 May 2020 23:28:23 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87tv0nvztm.fsf@web.de> Content-Type: multipart/mixed; boundary="------------8CF7A8AC6C890FA54032201E" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------8CF7A8AC6C890FA54032201E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/10/20 9:51 PM, Michael Heerdegen wrote: > BTW (also @Paul) there are some places (five or so) in Elisp source > files that look like > > (nconc '(x y z) (get-some-list)) > > Should they be rewritten? Yes, of course. Does the attached diff (against master) match what you found? --------------8CF7A8AC6C890FA54032201E Content-Type: text/x-patch; charset=UTF-8; name="nconc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="nconc.diff" diff --git a/lisp/emacs-lisp/byte-opt.el b/lisp/emacs-lisp/byte-opt.el index 4f72251aed..fd6c6fe1ad 100644 --- a/lisp/emacs-lisp/byte-opt.el +++ b/lisp/emacs-lisp/byte-opt.el @@ -1509,14 +1509,13 @@ byte-compile-side-effect-and-error-free-ops byte-current-buffer byte-stack-ref)) (defconst byte-compile-side-effect-free-ops - (nconc - '(byte-varref byte-nth byte-memq byte-car byte-cdr byte-length byte-aref - byte-symbol-value byte-get byte-concat2 byte-concat3 byte-sub1 byte-add1 - byte-eqlsign byte-gtr byte-lss byte-leq byte-geq byte-diff byte-negate - byte-plus byte-max byte-min byte-mult byte-char-after byte-char-syntax - byte-buffer-substring byte-string= byte-string< byte-nthcdr byte-elt - byte-member byte-assq byte-quo byte-rem byte-substring) - byte-compile-side-effect-and-error-free-ops)) + `(byte-varref byte-nth byte-memq byte-car byte-cdr byte-length byte-aref + byte-symbol-value byte-get byte-concat2 byte-concat3 byte-sub1 byte-add1 + byte-eqlsign byte-gtr byte-lss byte-leq byte-geq byte-diff byte-negate + byte-plus byte-max byte-min byte-mult byte-char-after byte-char-syntax + byte-buffer-substring byte-string= byte-string< byte-nthcdr byte-elt + byte-member byte-assq byte-quo byte-rem byte-substring + ,@byte-compile-side-effect-and-error-free-ops)) ;; This crock is because of the way DEFVAR_BOOL variables work. ;; Consider the code diff --git a/lisp/frameset.el b/lisp/frameset.el index 10c6914f52..5850561928 100644 --- a/lisp/frameset.el +++ b/lisp/frameset.el @@ -396,17 +396,17 @@ frameset-prop ;; or, if you're only changing a few items, ;; ;; (defvar my-filter-alist -;; (nconc '((my-param1 . :never) -;; (my-param2 . my-filtering-function)) -;; frameset-filter-alist) +;; `((my-param1 . :never) +;; (my-param2 . my-filtering-function) +;; ,@frameset-filter-alist) ;; "My brief customized parameter filter alist.") ;; ;; and pass it to the FILTER arg of the save/restore functions, ;; ALWAYS taking care of not modifying the original lists; if you're ;; going to do any modifying of my-filter-alist, please use ;; -;; (nconc '((my-param1 . :never) ...) -;; (copy-sequence frameset-filter-alist)) +;; `(((my-param1 . :never) ...) +;; ,@(copy-sequence frameset-filter-alist)) ;; ;; One thing you shouldn't forget is that they are alists, so searching ;; in them is sequential. If you just want to change the default of @@ -445,39 +445,38 @@ frameset-session-filter-alist ;;;###autoload (defvar frameset-persistent-filter-alist - (nconc - '((background-color . frameset-filter-sanitize-color) - (buffer-list . :never) - (buffer-predicate . :never) - (buried-buffer-list . :never) - ;; Don't save the 'client' parameter to avoid that a subsequent - ;; `save-buffers-kill-terminal' in a non-client session barks at - ;; the user (Bug#29067). - (client . :never) - (delete-before . :never) - (font . frameset-filter-font-param) - ;; Don't save font-backend because we cannot guarantee the new - ;; session will support the saved backend anyway. (Bug#38442) - (font-backend . :never) - (foreground-color . frameset-filter-sanitize-color) - (frameset--text-pixel-height . :save) - (frameset--text-pixel-width . :save) - (fullscreen . frameset-filter-shelve-param) - (GUI:font . frameset-filter-unshelve-param) - (GUI:fullscreen . frameset-filter-unshelve-param) - (GUI:height . frameset-filter-unshelve-param) - (GUI:width . frameset-filter-unshelve-param) - (height . frameset-filter-shelve-param) - (outer-window-id . :never) - (parent-frame . :never) - (parent-id . :never) - (mouse-wheel-frame . :never) - (tty . frameset-filter-tty-to-GUI) - (tty-type . frameset-filter-tty-to-GUI) - (width . frameset-filter-shelve-param) - (window-id . :never) - (window-system . :never)) - frameset-session-filter-alist) + `((background-color . frameset-filter-sanitize-color) + (buffer-list . :never) + (buffer-predicate . :never) + (buried-buffer-list . :never) + ;; Don't save the 'client' parameter to avoid that a subsequent + ;; `save-buffers-kill-terminal' in a non-client session barks at + ;; the user (Bug#29067). + (client . :never) + (delete-before . :never) + (font . frameset-filter-font-param) + ;; Don't save font-backend because we cannot guarantee the new + ;; session will support the saved backend anyway. (Bug#38442) + (font-backend . :never) + (foreground-color . frameset-filter-sanitize-color) + (frameset--text-pixel-height . :save) + (frameset--text-pixel-width . :save) + (fullscreen . frameset-filter-shelve-param) + (GUI:font . frameset-filter-unshelve-param) + (GUI:fullscreen . frameset-filter-unshelve-param) + (GUI:height . frameset-filter-unshelve-param) + (GUI:width . frameset-filter-unshelve-param) + (height . frameset-filter-shelve-param) + (outer-window-id . :never) + (parent-frame . :never) + (parent-id . :never) + (mouse-wheel-frame . :never) + (tty . frameset-filter-tty-to-GUI) + (tty-type . frameset-filter-tty-to-GUI) + (width . frameset-filter-shelve-param) + (window-id . :never) + (window-system . :never) + ,@frameset-session-filter-alist) "Parameters to filter for persistent framesets. DO NOT MODIFY. See `frameset-filter-alist' for a full description.") diff --git a/lisp/gnus/gnus-sum.el b/lisp/gnus/gnus-sum.el index 6f367692dd..595df607f5 100644 --- a/lisp/gnus/gnus-sum.el +++ b/lisp/gnus/gnus-sum.el @@ -1501,9 +1501,9 @@ gnus-summary-mode-line-format-alist ;; This is here rather than in gnus-art for compilation reasons. (defvar gnus-article-mode-line-format-alist - (nconc '((?w (gnus-article-wash-status) ?s) - (?m (gnus-article-mime-part-status) ?s)) - gnus-summary-mode-line-format-alist)) + (nconc `((?w (gnus-article-wash-status) ?s) + (?m (gnus-article-mime-part-status) ?s) + ,@gnus-summary-mode-line-format-alist))) (defvar gnus-last-search-regexp nil "Default regexp for article search command.") --------------8CF7A8AC6C890FA54032201E-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 13:58: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, Richard Stallman , Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158920546714423 (code B ref 40671); Mon, 11 May 2020 13:58:02 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 13:57:47 +0000 Received: from localhost ([127.0.0.1]:52872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY8wF-0003kZ-5c for submit@debbugs.gnu.org; Mon, 11 May 2020 09:57:47 -0400 Received: from mail-qt1-f176.google.com ([209.85.160.176]:35706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY8wD-0003kJ-SJ for 40671@debbugs.gnu.org; Mon, 11 May 2020 09:57:46 -0400 Received: by mail-qt1-f176.google.com with SMTP id x8so7857474qtr.2 for <40671@debbugs.gnu.org>; Mon, 11 May 2020 06:57:45 -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=Wwx6wahubZInRPIgH/Nw2lMu6pDzOzofd6TuOge2GbI=; b=fOESu3mErYjQ1Q6dfx9Qk+E56G6z7FOT4yBvv5ggy9+yPfPARN/eETS5M/GLTXc9Yp P+KPkixR1mkgaAYcPzvSpTVlhxY25zZIPLNcgr/xskejmdyTWiFomOQothhKaEZ8PIQz D9fvKExdyOYnAklxNQiBL10IohF52vy4v2/PJWrb+F7kVCpYD1gUP/tvOtkOSNHpHDZ3 nkbpcqsT9YNMP1Vt6omyTvn7g0v34UOYVyfF+hq/Kb8PIwLylrXwKumv1EFW1kohlR3t hVfhej/fsMfQ6eWGFeQQYiOOPda94LIX+Jo7GlkgswVBsJnYWavwLb1MWuewIS+3O4ED kDwg== 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=Wwx6wahubZInRPIgH/Nw2lMu6pDzOzofd6TuOge2GbI=; b=OvrdWdmmbtI3uF3PFW+3fxmXc4ttEOY40IPo93GQFa2JYDYXmnRNBYqeObnsxA5VgE H3KUNvyNK27hOmlBmcKQ1wox9raO63Z2lk73KsKhTWSc4fdRsVWWU+44/0CGliVhF6wG uNQ8SpL5PW930KKdfcSZ7Q3US/PUXOXkR6weeNKfwZFFb8bbbloqeQixHm7TyDwd41LD ye4aNAfr1YgymK7gxJl9XviK/wNuQnodBPDwFrQlsLLClWaSusCgHjf09pJPHxP7osTi yYa8QENHNPcAh4CRJIY+a7QNZMhiF50JvUP165BI655HYFTBvxgPVQqC2+jv5qqmT/j5 PYeQ== X-Gm-Message-State: AGi0PuY/VTWo5uKLpTD4aR46bGeVB2p+nvN7W7V5DL/17MgKXszhXV+E szDjKLIBALK+7SMLDf2EHx8= X-Google-Smtp-Source: APiQypKYXu3Gzr6PEi2mU0VmlHT/jllVkVgjNnGkqJwkzwG3S/YbmFKmv/iZMH+R6PAHzUbXF+Vkow== X-Received: by 2002:ac8:4b50:: with SMTP id e16mr16498782qts.26.1589205459949; Mon, 11 May 2020 06:57:39 -0700 (PDT) Received: from vhost2 (CPE001143542e1f-CMf81d0f809fa0.cpe.net.cable.rogers.com. [99.230.38.42]) by smtp.gmail.com with ESMTPSA id h13sm9274244qti.32.2020.05.11.06.57.38 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 May 2020 06:57:38 -0700 (PDT) From: Noam Postavsky References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> Date: Mon, 11 May 2020 09:57:38 -0400 In-Reply-To: (Paul Eggert's message of "Sun, 10 May 2020 23:28:23 -0700") Message-ID: <857dxih8vh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Paul Eggert writes: > (defvar gnus-article-mode-line-format-alist > - (nconc '((?w (gnus-article-wash-status) ?s) > - (?m (gnus-article-mime-part-status) ?s)) > - gnus-summary-mode-line-format-alist)) > + (nconc `((?w (gnus-article-wash-status) ?s) > + (?m (gnus-article-mime-part-status) ?s) > + ,@gnus-summary-mode-line-format-alist))) You meant to remove the nconc call too, right? From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 22:32: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Drew Adams , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158923628721201 (code B ref 40671); Mon, 11 May 2020 22:32:02 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 22:31:27 +0000 Received: from localhost ([127.0.0.1]:53583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYGxL-0005Vt-6U for submit@debbugs.gnu.org; Mon, 11 May 2020 18:31:27 -0400 Received: from mout.web.de ([212.227.15.3]:53831) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYGxI-0005Ve-Ki for 40671@debbugs.gnu.org; Mon, 11 May 2020 18:31:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1589236259; bh=8tAZwfb5WISkZg00rTl4lbKmePbAjJBAhJiaxI33ydk=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=K+mlZGWMtrmAAnWUFa0H2+Y1hG1AXJBG6iRNEtpKiPaa7E9mWlh/M28pSHD+kao12 klRStvmOoIizudl9AAf6gJwHJxVQWD0QlaOZWcSsiCLkW3cUao5f08o2ROlPGQb+AI qPSeFeX5FrbBEnNSHpB7Vt6Zx+cf5fLnAfadKRns= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.107.170]) by smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id 0McWno-1jpnpi465I-00HbgB; Tue, 12 May 2020 00:30:59 +0200 From: Michael Heerdegen References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> Date: Tue, 12 May 2020 00:30:56 +0200 In-Reply-To: (Paul Eggert's message of "Sun, 10 May 2020 23:28:23 -0700") Message-ID: <874ksmqf33.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:XGtWpWVoozWcGavs0SpVoxqT82zAv1EKy4YgEqxcKS4FHhEnM1o RJWldgjrKPvE1LkcTq5rytWyYTDLzUVMeBfTbgq4D0h9kOR4b+0kbxYxagdqm+q6xxxYlkj rv9viDoJA8ad2ggVhhS/NhnkiF75Oj+vnNY1GIX5MN8fFv429dmHl2DSGncLEM77Cc9fbL8 bJxrDy3SBUHQaNx8PeOaA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:a9K2lW+hSQM=:krAISQxy45eCuioj/11GEt HyzWuwYxrW+OlJU5QMbboBvmM4L45akodCIjgXjaRdJY0Q2JDyiJJWckChVkvLwP98kAe5kK4 KJFVrmDMLwHO7hqrMSJI/IX0ru+zEq/TCOEm+vPQrasNeT1OsHYG9rFIUTGwMMkLIp9Tknv16 1Mq/Hx1vVSZQ2vB7snz/lvUS3Ru3li6WlYnj3PsSFvnsgywpNSuV8QJn409jDgydpusQ3MfNg SOtr4npePHKHZ1U9oiYxsULkj1Yp5OUHfWlNgyKpGU7Z6Ht9VeutnQDh4Fqe7EmIX1zitpmFv Z3DYgfMtliqg89BFg9yfWintkott6O2+OKQxGwcGtk4R5O2u67i8ICLP2LEqVdkZAPAu9a/pe NC7lx5hkgIvGyA5/LWETBmOXWoLfa0t3fstSWOmI6w5qK12zGzohsDDchiuUqQOTyftJAgt6q KibNzQ+8goMfWWuOjswCwgQS6zcFHKjWMWB8iBP34evCpfWtBkfT+68v6vrhAHC8US9eWqzE+ Nl0TyIzp3xiojlXxYsaGrlZT3NmZnixfXYW7JYkjM3Gw1i+A+xAbZuAyY2GxWb6d8Fwy446Ax jaOEFSKnObghT0B57s/0orI/y/g/xGwES2bS8xCYCIQIB8XQNTwAAGAPuDFhT28f+Rc0GdQiy 0Hwk6b2SjH5hWPGnOQV1CxyGSiHDyV13vx0I4O1bwvU8/x5APvf4eJldkaRVMzG5KonqEIv3r KKkoba+gq2dtkDLwSNFU5plhMD4LeqhMG/B9t5I+MT0F2BNULhdWJL0zNGPKtU/lqNCir1DXE OusL7SNZI0Z6E9KNd5E1oSjQH5oj+/OQ6YgsrBofpJ7H1azDB7dcv0WRayyD0VXAmhMT/lOFl 9TRbu/gRsRPyE+LhbIxcG3WzJpNxxckH4Qxk8vICxjwfZaSu2h7YrL3BezibLfWUStln6zof7 OOvytqdnUjv44CLCdOgV5IxlWeAmuFVh49UEzGYLYe5DIXVcVa4piCRGAAm8VjFZxij8A+uvL 9ovYEn4CZE5MTSG7rR8xA+U9ksNHY9dd01DPMISd4apyhhsTQOKsP45vHO3LNj9nE+HgN9inA eAXweZEWGiIg3GcKPZ4Eq5RoZi48mRPFRyhZEURYEHjkzVg2LpE1CEQMDFkIfExNYgOVMK8pY daadvkzRwMZn4olRE4sGuzWY4DZPaPAWhjaP0s836cR1kKkpsqOspGu5HkFV/Bzi5Z3SXZxq9 DiRNSFBm3bp0ZKAa0 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > Yes, of course. Does the attached diff (against master) match what you > found? Yes, I think so. Thanks, Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 22:37: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 To: Noam Postavsky Cc: ke.vigouroux@laposte.net, Paul Eggert , 40671@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Richard Stallman Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158923660521753 (code B ref 40671); Mon, 11 May 2020 22:37:02 +0000 Received: (at 40671) by debbugs.gnu.org; 11 May 2020 22:36:45 +0000 Received: from localhost ([127.0.0.1]:53588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYH2S-0005en-S3 for submit@debbugs.gnu.org; Mon, 11 May 2020 18:36:45 -0400 Received: from mout.web.de ([212.227.15.3]:53405) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYH2R-0005eX-BY for 40671@debbugs.gnu.org; Mon, 11 May 2020 18:36:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1589236590; bh=SKYXxKX9D03xBonn+ys+kSep/sZqzTipAozmgST+k4c=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=IQh76fHu7NHwn4/m14CzBy0IDn5h/jEGygCkTtsBGJ/uKAMTQ7/ftDcVZNqfYfAba 2XuBEyAgWg0FOnr7Ft6zuK8Q8oF09qdJVXCTcEC6vmadVbqlNCs17Be9CA1M47vxVL R32cYdoKbwCppFWvflI9cYbr+JvL89YW+HyKf0Y0= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.107.170]) by smtp.web.de (mrweb004 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MCvVz-1jPmRS2xYB-009fUB; Tue, 12 May 2020 00:36:29 +0200 From: Michael Heerdegen References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> <857dxih8vh.fsf@gmail.com> Date: Tue, 12 May 2020 00:36:28 +0200 In-Reply-To: <857dxih8vh.fsf@gmail.com> (Noam Postavsky's message of "Mon, 11 May 2020 09:57:38 -0400") Message-ID: <87zhaep09f.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:rUbuMLu48WvhTy1h9lHpbdgBuCTQnKfxLPPGeObYMcF0FQwf2S1 vN1N1yaBBRevlkjGrVkzsNPmvpZq5Ap+VZkANZi7Wb/Nt/AqMkA4T6gQyziqcsRv5U0DJmq ugYWDXOH78G8kuqCzDUyYfAI9WHRt+f/M2VwxIUFJHqOaW8ywyjcxyTX9U63Q9iJvR965d9 Qc6ZHfl3k0cuUQ3WGp0Bg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:nqmfD/lfVFo=:QsIMiiKOOaazPOqRkkVXDz oKvKI92pVjXURNMKvCf8TquCgGW3Lu7k1D1gGKVLzFNtUbefeBkmY8ZVKRiKE2SjR1jj9h9Mv R7MgFXN+tiIHC8MLLHM5s+EKlsbwR/fY4kr7bLFyIwwQcd0UDomoZkY5XEBtZi0v/mCtmQM5z lY+DGxV88gN3qy8sSb+T0+03+lg3kbVXF20sEDWWJUZdFvG2Uz9Y/bQp/ZxVOtyOMkhlKSvZw 6c1VBrsE3A9YnPyEsK7m67U1ND0Tv3ERGzmsDlCgmAdBIOaCDfbqBQhksLV2eeVRhoKtpwA9s /K/O36T+BgalAwfeh+WwYcmGgPzYBjTjV0p5+HSXM1e3p31S3HPcN+aTogXJv3Nk7xOZAotwE 6j2X0W/DLm6yBn6d7xX51v5RNczuP8r73uwia03Sj/PHV67khKFK+UUL196pJRJUc5/p0NJmd /sNWGugMceReYSmNRt+zv/Ydv8Xo4E4Hy8zV8zD96M5eHAgNm06raKeNo6d/NIVsK2riz+Awg 4gTZW5RyOh4VjrDQ60Gq/VuaBG0oHLsRJ2kihS0UxSIO4N2WGC0kss6ijBRpFKov35nJ7/BqS /OjrAlRAmXB81wKQf84FpVzmGDAZ0PmqTF3esgvjrDPe5JxEq3+07BM0atCxNz1B1QzgDtPr3 DlarPPLud8ra0wIiM80xALoau0Pn9EoeSnGMNLC68JxMlrHLepZVodk7yskisJFO1L4o/TmjA ldTAamX1d9Fr/KzHde4enHBZ7R2b20CrjnfDb/gKUZ61NDVqSyKQw42Jw/dR0czBHzKmjh/iL EP2Gj15DVpUz5JMKRBDqjqTgXtJAoH19PJt4G9wf7Y2hQTyKAskA6MfHpXytbZPHi+LPw8a9F yA74QhmFbJ834eeULlPMWK46hcBtAHHapi+db6N8qKS8f8c0UhitOe8+QJmtaYIZkv+Q6yhjY qvQECjd4Ae7031Dg0X3rofb3CjPPha8xaZnxg3SmfyKcnYdNVIkZg5AReES7fpbvrTalFTmEE ZDLmnPQi3N6jTnNWOMWlkRGdlVmc5qNFf2xwIazg6i/2kymC1fTzDC7Pr2DGdLtCM+SP1+0Ww Uq80TH1XqFYI/52AynzzsEfERMqGdI89Dlx3ML8YXP+Y2FdLOYOmhTGzmRSxTtMvQq+JG/hiy Z7XcQ6ggqp2asMPAmD1piSCmEs7QiTv5+8xIwulW8En1gj+oew0q996Vg8mlXVNN1997jCyTS aWLcZ5qMeRA4y42gx X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Noam Postavsky writes: > Paul Eggert writes: > > > (defvar gnus-article-mode-line-format-alist > > - (nconc '((?w (gnus-article-wash-status) ?s) > > - (?m (gnus-article-mime-part-status) ?s)) > > - gnus-summary-mode-line-format-alist)) > > + (nconc `((?w (gnus-article-wash-status) ?s) > > + (?m (gnus-article-mime-part-status) ?s) > > + ,@gnus-summary-mode-line-format-alist))) > > You meant to remove the nconc call too, right? That, and, the code still makes literal lists to alist entries. If you modify these associations, you modify these literal lists. I wonder how many of such uses of backquote expressions used to construct alists are scattered throughout the Emacs code. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 May 2020 02:01: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 To: Paul Eggert Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15892488029469 (code B ref 40671); Tue, 12 May 2020 02:01:01 +0000 Received: (at 40671) by debbugs.gnu.org; 12 May 2020 02:00:02 +0000 Received: from localhost ([127.0.0.1]:53752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYKDB-0002SU-S5 for submit@debbugs.gnu.org; Mon, 11 May 2020 22:00:02 -0400 Received: from mail-wm1-f47.google.com ([209.85.128.47]:36271) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYKDA-0002Rz-1X for 40671@debbugs.gnu.org; Mon, 11 May 2020 22:00:00 -0400 Received: by mail-wm1-f47.google.com with SMTP id w19so6731947wmc.1 for <40671@debbugs.gnu.org>; Mon, 11 May 2020 18:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=M1SD4ht8C3PdDpjeKkzjZZUm5ouR4fBcvFhOR0m0JqM=; b=Iz75uXH9FZwZuHovmuZLtfu3+7PXpWE37MF5wpbqrifYrRlszCd6nnjls9DqQvQsDp djlAxMJEMLg0MmAEQipemVLFji6XiYfNLWg19m2OfPZjIBB+DURXgus2WP4eUPsLzG1g k7S5fxYvj6h7c6GvITe6kYWGgGnGQUZimfbNg83MIRGFfNcir+JyeCjVK+vOKk0X0PyG BCcQNfip2Lj/Hy/sHF3CUPCPMfSP/sown1OxcIrAmZ5K65tx7sUVxekB2gdxlRcYNCKG D+Urx/vugl80t8/bBqZiG3zIb4g4w9NE8leYmMGIYzMVaYUDVAWqzBj3nNAcP+QRkq0j Q/Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M1SD4ht8C3PdDpjeKkzjZZUm5ouR4fBcvFhOR0m0JqM=; b=DQgHlh+9U5ju/0SWGwLrQE0E+5ut2QikZ+AV8+sOr6+4sHbDtdWXk7c0q/jncXQoWG H8xmty/UdJoAeRfYOZkOMo2q0aXC+1TjxpEmWszvIJ6q7w7wKNOOR8RECwhSxfzcqgHR c5rEMWofclK/oEAyfU1HQjOPOXnGWWI84JGSd9YV/oKAUREzp0inY0fZ0PL8//EvQK87 L0NpxS9UjabZOxayWqkz09CpqfXNTNaSe6O+nxpH89pCAsCgJSyE+9Pm6ibZnvIHmIpd qGUXmpHTZJewTPdGOnb65d24ug3UWvpwxTkQ/3XIEqC3YWmPxH4leF/FXizd0myQnbmS 0mKw== X-Gm-Message-State: AOAM532xaHt5530Jl8XBq89Dsgfm/9GTHZbHnBkwLh5YlZUEontGynHA pWOmYF5izZvzDz9j2P7it9o= X-Google-Smtp-Source: ABdhPJz5kafpwqMNckWhdJSSDSH+dKDvjJSmgbOPjxGETjTgDy/5lvEAb/bfYa5rvQNI5aTyrSQhiQ== X-Received: by 2002:a1c:7914:: with SMTP id l20mr784188wme.120.1589248793934; Mon, 11 May 2020 18:59:53 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id r2sm22539996wrg.84.2020.05.11.18.59.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 18:59:52 -0700 (PDT) References: <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> <4ba236ce-ade0-5cd1-656a-f2df46d67d5f@cs.ucla.edu> From: Dmitry Gutov Message-ID: Date: Tue, 12 May 2020 04:59:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <4ba236ce-ade0-5cd1-656a-f2df46d67d5f@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 11.05.2020 04:57, Paul Eggert wrote: > On 5/10/20 5:44 PM, Dmitry Gutov wrote: > >> "Indeed"? > > Indeed yes. :-) That paragraph doesn't scan. You could replace that word with "And", though. >> The changing "mutability" status is imaginary, however. > > It's part of a spec. Not every constraint in a spec needs to be enforced > directly by the implementation. That doesn't mean these constraints are "imaginary". Part of the "spec" you just added in this series of patches. I think that's exactly what a "constraint" means: something that is enforced. >>> Because it's not an accurate statement of the problem. The set of objects that >>> might be shared differs from the set of objects that should not change. The >>> Mutability node focuses on the latter set of objects, and gives the former as an >>> example but it is not the only sort of object that should not change. >> >> But if we don't mention such cases in "Mutability", where do we cover them? > > Fair enough. I added an example of such a case to "Mutability" in the proposal > in my most-recent email (Bug#40671#441). Curious case of an meaningful reference where I have to construct the URL manually anyway. The symbol-name example? I'm not sure it's really important to warn about this one in particular. But are we effectively saying "there exist values that are unsafe to modify, for example, any return values of symbol-name", and that's it? When one tries to describe "unsafe" things to do, they don't just give a few examples, they usually try to cover all cases. Perhaps by including some false positives (which the 'let*' example below, I think, is), but trying hard to avoid false negatives. 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? By the way, I have read last two paragraphs of that section now. C and "constants" are still there. >> +(let* ((x (list 0.5)) >> +       (y (eval (list 'quote x)))) >> +  (setcar x 1.5) ;; The program should not do this. >> +  y) >> >> Why is this a problem? Do we expect this it could lead to a segfault? > > Probably not a segfault in the current implementation, but the behavior isn't > defined. And we don't want the behavior to be defined, as that would prohibit > some optimizations that may be coming down the road. I'm curious to see the discussion about actually making this error at runtime in one of the next Emacs version. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 May 2020 03:21: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 To: Paul Eggert Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, michael_heerdegen@web.de, mattiase@acm.org, dgutov@yandex.ru, drew.adams@oracle.com Reply-To: rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158925365717583 (code B ref 40671); Tue, 12 May 2020 03:21:01 +0000 Received: (at 40671) by debbugs.gnu.org; 12 May 2020 03:20:57 +0000 Received: from localhost ([127.0.0.1]:53858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYLTV-0004ZX-2t for submit@debbugs.gnu.org; Mon, 11 May 2020 23:20:57 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYLTS-0004ZI-Ia for 40671@debbugs.gnu.org; Mon, 11 May 2020 23:20:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58533) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYLTM-0005OS-L5; Mon, 11 May 2020 23:20:48 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jYLTL-0004yC-Os; Mon, 11 May 2020 23:20:47 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: (message from Paul Eggert on Sun, 10 May 2020 23:28:23 -0700) 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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> Message-Id: Date: Mon, 11 May 2020 23:20:47 -0400 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Would someone like to search all our Lisp sources for "(nconc '" and check every occurrence? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 May 2020 04:26: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 To: Richard Stallman Cc: ke.vigouroux@laposte.net, Paul Eggert , 40671@debbugs.gnu.org, mattiase@acm.org, dgutov@yandex.ru, drew.adams@oracle.com Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158925751523908 (code B ref 40671); Tue, 12 May 2020 04:26:02 +0000 Received: (at 40671) by debbugs.gnu.org; 12 May 2020 04:25:15 +0000 Received: from localhost ([127.0.0.1]:53875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYMTj-0006DY-9e for submit@debbugs.gnu.org; Tue, 12 May 2020 00:25:15 -0400 Received: from mout.web.de ([212.227.17.12]:54007) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYMTh-0006DH-9i for 40671@debbugs.gnu.org; Tue, 12 May 2020 00:25:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1589257462; bh=az2w4WtA6E5n4Jdr/iVXe3tknVbqVvotL4NkPuVaF0o=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=okIfxGai+FHp+Gi5T6eNqhf4jY1JGx860QMRrpOfeu7snZOHKckn3LQRzQvpx9KHI vIR0yeWmHWqmNc31Cc+Zr4uUj5aRtHPHGkrHNbS8y6PfV1NrF8/TZkAvmq09Hu8PA9 OHJq54mzM/FNMX7I5elkABKKxv+F4fxTrL9Ah1qg= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.107.170]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1N0qvH-1jDxOV2JRF-00wloT; Tue, 12 May 2020 06:24:22 +0200 From: Michael Heerdegen References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> Date: Tue, 12 May 2020 06:24:20 +0200 In-Reply-To: (Richard Stallman's message of "Mon, 11 May 2020 23:20:47 -0400") Message-ID: <871rnprdaj.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:ARvsHnyaL36QpdK4FByG6KEa5VJPcgBo13JR4xf/4HNsB6iTfFo i+YgU6HlrZ2rGK6TpdJFgL/hh320IVgpkPiL5rF6a8q4SoGSD4pcnNTU4Oi0lPR6I9jyIQ2 4o47F2QyYKhWx7X8ddpFUdkl3g8MYPtNmo+W4r9PFxWsoBqdgOL6dQH2FaENio3E0vQZAt9 2QqAXWXXu9LbaNHGP1hiQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:PApjmbykMHY=:RUXRTrGdHsAFnXf9V+0eie t5mqFsdDg6kKf8FX7lsMu+ZQRVXHzhH7NWsYbZK9VpwLvohlYgi3lSlnFH/qGTmbu3CaXJkOZ lHbzi+Omdu3fSCshPq8jNe81nDhbL0z230hlunI9UnQH57nVNyAR9KLf5jhSwRZNvIgmu7kbC d8ff0toVqKb99aV+bo+1vSwOtZc19/Gdh3TWyKwRQ0rpXEzm8ubtV0SKFQKVuXsX2EpwmJUdC AtUnW1GjzLv9US6odhgx4cHKpW2y0q9+sXHGrebnQ30thq/H0q9fxgzZdUGzlfxcBfiWC/3Om jGcCgk6HJcmQD4hykrZkPhcX4KmK58zvEuWFdBE63gbYUSWl6QIKuUfcxqFXt8p3oXryvgcDp 6z0GZQADrBO2L28/+cA87tEQ1mfVrxGJ6x4A6XeJx0fAjxG+RHIcHxQTneuyn2qfd/RpRLbDN rfzYnehjzCzMeF8tXLNHfCIuTJhaSPZa3L6AAjpGculvc2x4Y1UO/osZHXY8RYvaK74M6H2aM YY5NuJy4GOhU9SHkMpWeZKPdQj/O+ohOzZaGVwm8uvNytfCsdLssohu0L1dxa8ruNAPTrJ4Z5 byE6JDOgK++FIqsy2tsOC9VGhjva+fZh0L3imqAj2UMsr64EJJrSRNYNx7kNROlHDv57SUX3L PxPY2ett3nfvOOb5jnPkMsfWngKss7vA6VZD/5dEgugyUCIyubGJPYmQ/cr2+bwM6x3lmzE9w 2AY4aN4AxDx6hf4qGzItrzjyRRWaViLzQJsdwQayjjhFZc+LK6nFuRbywQ5XERdJ//JX2o+p7 aHlH3nbSft9DF4uu2k3U+LuvzUDnLqAbucMZmgZ+2kgRBi8crNJ3UpEsj1Od3qjDumCBOP0I3 1PXHtMyB+8u8gN2w4gg/ubja+L31UItKE7qvekRmLinW8v6DiqucbzZsRee114yYIjiOCrQ2a C1pUncHL9d+gG7g8VUJ5tgVG03B2+l8idHVPSlJHSNz+LeMt2TKAYLTy8wgSMLYkwElJEABVK 0gF5WXmGJATFKAqcCZWdfN17yDoSJKARQ2y8pgQIWbvip/dhITUG06qqrsQbzoL7+NUagrJYu pW7IDBUS+PYv/nbMO2Dln2U+5my9JgDN/dCoBRRw5cqqGDKeCfhF8pYiQtCUnMCpMc3KdkE4s jQHuF7bmjk1qOhIVyVsSry1awCq29f+3R/IWLm+ZWTpBrBJsJHfxblU7rHjYregJp+AhAUM0j 5tUPCpC7eMgl/Nhi8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Richard Stallman writes: > Would someone like to search all our Lisp sources for "(nconc '" and > check every occurrence? Paul and I found the same matches with probably different methods - so I think this already has been done. Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 May 2020 03:58: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 To: Michael Heerdegen Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, dgutov@yandex.ru, 40671@debbugs.gnu.org, mattiase@acm.org Reply-To: rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158934225315774 (code B ref 40671); Wed, 13 May 2020 03:58:02 +0000 Received: (at 40671) by debbugs.gnu.org; 13 May 2020 03:57:33 +0000 Received: from localhost ([127.0.0.1]:57084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYiWS-00046M-NS for submit@debbugs.gnu.org; Tue, 12 May 2020 23:57:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYiWQ-000467-PF for 40671@debbugs.gnu.org; Tue, 12 May 2020 23:57:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56851) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYiWJ-0007XI-4T; Tue, 12 May 2020 23:57:23 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jYiWG-000118-BZ; Tue, 12 May 2020 23:57:20 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: <871rnprdaj.fsf@web.de> (message from Michael Heerdegen on Tue, 12 May 2020 06:24:20 +0200) References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> <871rnprdaj.fsf@web.de> Message-Id: Date: Tue, 12 May 2020 23:57:20 -0400 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Paul and I found the same matches with probably different methods - so I > think this already has been done. When you found them, did you fix them? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 May 2020 05:06: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 To: Richard Stallman Cc: ke.vigouroux@laposte.net, eggert@cs.ucla.edu, dgutov@yandex.ru, 40671@debbugs.gnu.org, mattiase@acm.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158934635922968 (code B ref 40671); Wed, 13 May 2020 05:06:02 +0000 Received: (at 40671) by debbugs.gnu.org; 13 May 2020 05:05:59 +0000 Received: from localhost ([127.0.0.1]:57121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYjah-0005yO-E9 for submit@debbugs.gnu.org; Wed, 13 May 2020 01:05:59 -0400 Received: from mout.web.de ([212.227.15.3]:36741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYjaf-0005y9-QR for 40671@debbugs.gnu.org; Wed, 13 May 2020 01:05:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1589346319; bh=EiP7pDC1GcibdURbRUnC54tFznb0yIDCyys6lDYOvYw=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=Lar5/8lkwjLolPR2dut6Miw1gQwEoNtJzfTepMQOiNYzqhz1IkNozKSf5oQdC6QZ6 2kWgMxx2ttXFw6wqYShhn/f7yuZsTw6nDqTIwnGT2O3PRMuNqVKq+b22nXYGVGWyGl r7x2bh5NxrFMm9p1o/Utdv0oRwqg0j36x+L1GqHA= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([88.67.107.170]) by smtp.web.de (mrweb001 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MCZP8-1jPQBp2hpi-009SGn; Wed, 13 May 2020 07:05:19 +0200 From: Michael Heerdegen References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> <871rnprdaj.fsf@web.de> Date: Wed, 13 May 2020 07:05:18 +0200 In-Reply-To: (Richard Stallman's message of "Tue, 12 May 2020 23:57:20 -0400") Message-ID: <87wo5gfmr5.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:XatbE6AEfsm0EMhZ+NwXDkb/gqHRxf2g/mAuw/+GgFAAbzwMIFM ZnlSH+pHcn5nZ7a/msSSSSz2xvBjyQccdMPHtbyvDNYYNAQvzlS4ydb9k5M1IqsFlewo8j+ 2GWyh6h29PIaa1s5FDcwtT/1OSczyEXfxZIAySW5L0V9C/dAWO6aUOLgQsY6fsevj/VFAXW +0ToWbBfNy4ocpfqLqdyQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:DZcFvsc0R14=:tA+bxbNVt4J454f6t+bPE3 1P81hc6qHDcSZ32TyRSeta8RStCO9yOmLIp+Kvuk6NLAftVjHGyyGF/9Qz6eyj8qwamespuBY +GMh48K3L/o3nnB1Rmv9l61J0Z9FxXQWnWXjaDQE7iiJqcAkLZh0JHeLAtrFNvJ5gArUTX5xs bhC+CsxkyXI+/MB9IWPp37CxpMztkpZFYVKsxICURf0+ib/Hd4C8Fjm6z2tTRpLtcJ+ajyOur OZ1hHw4n4TzkuMeQslsUjImr1bB4OwkJkMMz0k2KPTCbpq4XQPge651MRwk5CHKKuQMCNxH1m 8Yja9ngiAd8UcPtZ5etzQlFlDjGH3kwxF8yZVzdfjCLK/Po0Md00MDalQXH4SXHPaSgvW4WjE w8Ab5Djw31lnsysTuMtpAN577v7B4L6jrUy0NWJz/VwfvbChmGxHtkyANJRRLHi9EtQTl2QS9 zm4TCYLMvgqEnO/sRT/0D3ijum2ulgD35UDYW+IRNPqr8Y5ZFYS6qKQGxWXsrWaVhP45x8kVb rEbPKx1+LnbYZvGxQDNkN48T/57rrJqB9lw3wXbYxSSKFTvUB3I48/pxYAi1QQhMUBUpd8efh phs9NyZUDGdo3VD/WNJI7rubr3YJlq7iAGpJ5CLpkFDCjhCeO0JW/XlpfTLeZ5SwQBd1QqZsv J0WprTCq38Okzj/zINydVkRgUIPierxM9ckSKuKCvK5t4PpZLzGKuKl3pabSiyzJVen0uZfvw 0kZ0eqy6ghpRlPqpCej+Qh3nK73zZ2n40EUc8jB6EfiWSI/M+ee6rZypWd4kqv45GeWrp8kOM +On9XbAGzSdIpjkTCb5pIENJimGf4W07G2XlHufqGizzchVtMWUzMtL1eDt1BoF+LYW6emPrG kufBw8PV/IUdx1TRwjvV4AnGQBsowUOwZbHyQU07n+wDXwb+rI2S/2ChtRNPjg+icywyaKHoy Oohe9Nk+RRIMMnzxXtEo7t+zKbs0ikQ1ojwYCOQzaqdZka3WDkS7xsQKX3BMfZ7AQS1HDOC9A CSHpr17lofGYSWLUCPHx9xgy+VQzQ6TMGZBqXpnXqxMZ2RFZKthZcTiL4SDIsTgdkvfwTf8IH k4031MNy/Ye+oqeaMLd8SH5YWrYR54kyeMCOC6VpIqmQeCxmYd9W1ulLKVO8w6TKyTmD+9aFu PHHaK5cuC5S6grLD90wQBHtJXnJ7ZQuJke+5Few+BL0XDY6SNR3wLTGwyjgCHx6M4hLwogvD3 VyYVnEGQTswyZ1/PW X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Richard Stallman writes: > When you found them, did you fix them? Paul has already proposed a patch, I guess he will install it later (maybe after caring about the remarks by Noam and me). Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2020 05:15: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 To: Michael Heerdegen Cc: mattiase@acm.org, eggert@cs.ucla.edu, dgutov@yandex.ru, 40671@debbugs.gnu.org, ke.vigouroux@laposte.net Reply-To: rms@gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158943326019037 (code B ref 40671); Thu, 14 May 2020 05:15:01 +0000 Received: (at 40671) by debbugs.gnu.org; 14 May 2020 05:14:20 +0000 Received: from localhost ([127.0.0.1]:59995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZ6CK-0004wy-AF for submit@debbugs.gnu.org; Thu, 14 May 2020 01:14:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZ6CH-0004wk-VE for 40671@debbugs.gnu.org; Thu, 14 May 2020 01:14:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54397) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZ6CC-0001yv-GD; Thu, 14 May 2020 01:14:12 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jZ6C1-0007E3-Dp; Thu, 14 May 2020 01:14:02 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: <87wo5gfmr5.fsf@web.de> (message from Michael Heerdegen on Wed, 13 May 2020 07:05:18 +0200) References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> <871rnprdaj.fsf@web.de> <87wo5gfmr5.fsf@web.de> Message-Id: Date: Thu, 14 May 2020 01:14:01 -0400 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Paul has already proposed a patch, I guess he will install it later > (maybe after caring about the remarks by Noam and me). Thank you, and Paul. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 May 2020 00:12: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 To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Michael Heerdegen , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15896743028423 (code B ref 40671); Sun, 17 May 2020 00:12:01 +0000 Received: (at 40671) by debbugs.gnu.org; 17 May 2020 00:11:42 +0000 Received: from localhost ([127.0.0.1]:41942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ja6u5-0002Bm-PT for submit@debbugs.gnu.org; Sat, 16 May 2020 20:11:42 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ja6u2-0002BX-8o for 40671@debbugs.gnu.org; Sat, 16 May 2020 20:11:39 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4336D1600C7; Sat, 16 May 2020 17:11:32 -0700 (PDT) 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 ybGF0747ISta; Sat, 16 May 2020 17:11:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 599411600DA; Sat, 16 May 2020 17:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 QqFEXWzYea6R; Sat, 16 May 2020 17:11:30 -0700 (PDT) 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 F17911600C7; Sat, 16 May 2020 17:11:29 -0700 (PDT) References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> <05BEF593-F16A-4DEE-98BC-653221F1F9EE@acm.org> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <0e9e09ce-f129-b359-e9aa-5296708b0f45@cs.ucla.edu> Date: Sat, 16 May 2020 17:11:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <05BEF593-F16A-4DEE-98BC-653221F1F9EE@acm.org> Content-Type: multipart/mixed; boundary="------------142A667DCA6DCB5AE96ED9CD" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------142A667DCA6DCB5AE96ED9CD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/11/20 2:29 AM, Mattias Engdeg=C3=A5rd wrote: > As an experiment, I added an immutable cons type some time ago and foun= d these and more. The attachment contains some of the adjustments made at= the time. This isn't complete; I never got to a full bootstrap, for unre= lated reasons. Thanks for sending that patch. Even if incomplete, it's better to not try= to modify constants so I installed the attached into master; it's derived fr= om your patch and supersedes my earlier (typo-containing) patch about nconc. > By the way: Is there any reason you prefer `(a b c ,@tail) to (append '= (a b c) tail)? No, I just wasn't thinking. The attached patch uses 'append'. --------------142A667DCA6DCB5AE96ED9CD Content-Type: text/plain; charset=UTF-8; name="0001-Don-t-attempt-to-modify-constant-conses.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-Don-t-attempt-to-modify-constant-conses.txt" RnJvbSBhZWQxMTEwMGY4MDU2ODA0ZDJlNDM4ZmM0ZTc5M2RjMDk5ZDBlMDZmIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBTYXQsIDE2IE1heSAyMDIwIDE3OjA0OjE1IC0wNzAwClN1YmplY3Q6IFtQQVRD SF0gPT9VVEYtOD9xP0Rvbj1FMj04MD05OXQ9MjBhdHRlbXB0PTIwdG89MjBtb2RpZnk9MjBj b25zdGFuPz0KID0/VVRGLTg/cT90PTIwY29uc2VzPz0KTUlNRS1WZXJzaW9uOiAxLjAKQ29u dGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04CkNvbnRlbnQtVHJhbnNmZXIt RW5jb2Rpbmc6IDhiaXQKCkZyb20gYSBwYXRjaCBwcml2YXRlbHkgc3VnZ2VzdGVkIGJ5IE1h dHRpYXMgRW5nZGVnw6VyZCBvbiAyMDIwLTA1LTExCmluIGEgZm9sbG93dXAgdG8gQnVnIzQw NjcxLgoqIGFkbWluL2NoYXJzZXRzL2NwNTE5MzIuYXdrOgoqIGFkbWluL2NoYXJzZXRzL2V1 Y2pwLW1zLmF3azoKR2VuZXJhdGUgY29kZSB0aGF0IGRvZXMgbm90IG1vZGlmeSBjb25zdGFu dCBjb25zZXMuCiogZG9jL21pc2MvZW1hY3MtbWltZS50ZXhpIChFbmNvZGluZyBDdXN0b21p emF0aW9uKToKKiBsaXNwL2VtYWNzLWxpc3AvYnl0ZS1vcHQuZWwgKGJ5dGUtY29tcGlsZS1z aWRlLWVmZmVjdC1mcmVlLW9wcyk6CiogbGlzcC9mcmFtZXNldC5lbCAoZnJhbWVzZXQtcGVy c2lzdGVudC1maWx0ZXItYWxpc3QpOgoqIGxpc3AvZ251cy9nbnVzLXN1bS5lbCAoZ251cy1h cnRpY2xlLW1vZGUtbGluZS1mb3JtYXQtYWxpc3QpOgpVc2UgYXBwZW5kIGluc3RlYWQgb2Yg bmNvbmMuCiogbGlzcC9sYW5ndWFnZS9qYXBhbmVzZS5lbCAoamFwYW5lc2UtdWNzLWNwOTMy LXRvLWppcy1tYXApCihqaXN4MDIxMy10by11bmljb2RlKToKVXNlIG1hcGNhciBpbnN0ZWFk IG9mIG1hcGMuCiogbGlzcC9sYW5ndWFnZS9sYW8tdXRpbC5lbCAobGFvLXRyYW5zY3JpcHRp b24tY29uc29uYW50LWFsaXN0KQoobGFvLXRyYW5zY3JpcHRpb24tdm93ZWwtYWxpc3QpOgoq IGxpc3AvbGFuZ3VhZ2UvdGliZXRhbi5lbCAodGliZXRhbi1zdWJqb2luZWQtdHJhbnNjcmlw dGlvbi1hbGlzdCk6ClVzZSBjb3B5LXNlcXVlbmNlLgoqIHRlc3Qvc3JjL2Zucy10ZXN0cy5l bCAoZm5zLXRlc3RzLW5yZXZlcnNlKToKKGZucy10ZXN0cy1zb3J0LCBmbnMtdGVzdHMtY29s bGF0ZS1zb3J0KQooZm5zLXRlc3RzLXN0cmluZy12ZXJzaW9uLWxlc3NwLCBmbnMtdGVzdHMt bWFwY2FuKToKVXNlIGNvcHktc2VxdWVuY2UsIHZlY3RvciwgYW5kIGxpc3QuCi0tLQogYWRt aW4vY2hhcnNldHMvY3A1MTkzMi5hd2sgIHwgMTMgKysrKysrKy0tLS0tLQogYWRtaW4vY2hh cnNldHMvZXVjanAtbXMuYXdrIHwgMTQgKysrKysrKystLS0tLS0KIGRvYy9taXNjL2VtYWNz LW1pbWUudGV4aSAgICB8ICAyICstCiBsaXNwL2VtYWNzLWxpc3AvYnl0ZS1vcHQuZWwgfCAg MiArLQogbGlzcC9mcmFtZXNldC5lbCAgICAgICAgICAgIHwgMTIgKysrKysrLS0tLS0tCiBs aXNwL2dudXMvZ251cy1zdW0uZWwgICAgICAgfCAgNiArKystLS0KIGxpc3AvbGFuZ3VhZ2Uv amFwYW5lc2UuZWwgICB8IDEwICsrKysrLS0tLS0KIGxpc3AvbGFuZ3VhZ2UvbGFvLXV0aWwu ZWwgICB8IDE2ICsrKysrKysrKystLS0tLS0KIGxpc3AvbGFuZ3VhZ2UvdGliZXRhbi5lbCAg ICB8ICA4ICsrKysrLS0tCiB0ZXN0L3NyYy9mbnMtdGVzdHMuZWwgICAgICAgfCAzNCArKysr KysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tCiAxMCBmaWxlcyBjaGFuZ2VkLCA2MyBp bnNlcnRpb25zKCspLCA1NCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hZG1pbi9jaGFy c2V0cy9jcDUxOTMyLmF3ayBiL2FkbWluL2NoYXJzZXRzL2NwNTE5MzIuYXdrCmluZGV4IDZh YWM5ODgxNWIuLmMzNTU1MDk1MjQgMTAwNjQ0Ci0tLSBhL2FkbWluL2NoYXJzZXRzL2NwNTE5 MzIuYXdrCisrKyBiL2FkbWluL2NoYXJzZXRzL2NwNTE5MzIuYXdrCkBAIC00MywxMyArNDMs MTQgQEAgQkVHSU4gewogCiBFTkQgewogICBwcmludCAiKSkpIjsKLSAgcHJpbnQgIiAgKG1h cGMgIycobGFtYmRhICh4KSI7Ci0gIHByaW50ICIJICAgIChzZXRjYXIgeCAoZGVjb2RlLWNo YXIgJ2phcGFuZXNlLWppc3gwMjA4IChjYXIgeCkpKSkiOwotICBwcmludCAiCW1hcCkiOwor ICBwcmludCAiICAoc2V0cSBtYXAgKG1hcGNhciAobGFtYmRhICh4KSI7CisgIHByaW50ICIJ CSAgICAgIChjb25zIChkZWNvZGUtY2hhciAnamFwYW5lc2UtamlzeDAyMDggKGNhciB4KSki OworICBwcmludCAiCQkJICAgIChjZHIgeCkpKSI7CisgIHByaW50ICIJCSAgICBtYXApKSI7 CiAgIHByaW50ICIgIChkZWZpbmUtdHJhbnNsYXRpb24tdGFibGUgJ2NwNTE5MzItZGVjb2Rl IG1hcCkiOwotICBwcmludCAiICAobWFwYyAjJyhsYW1iZGEgKHgpIjsKLSAgcHJpbnQgIgkg ICAgKGxldCAoKHRtcCAoY2FyIHgpKSkiOwotICBwcmludCAiCSAgICAgIChzZXRjYXIgeCAo Y2RyIHgpKSAoc2V0Y2RyIHggdG1wKSkpIjsKKyAgcHJpbnQgIiAgKG1hcGMgKGxhbWJkYSAo eCkiOworICBwcmludCAiCSAgKGxldCAoKHRtcCAoY2FyIHgpKSkiOworICBwcmludCAiCSAg ICAoc2V0Y2FyIHggKGNkciB4KSkgKHNldGNkciB4IHRtcCkpKSI7CiAgIHByaW50ICIJbWFw KSI7CiAgIHByaW50ICIgIChkZWZpbmUtdHJhbnNsYXRpb24tdGFibGUgJ2NwNTE5MzItZW5j b2RlIG1hcCkpIjsKICAgcHJpbnQgIiI7CmRpZmYgLS1naXQgYS9hZG1pbi9jaGFyc2V0cy9l dWNqcC1tcy5hd2sgYi9hZG1pbi9jaGFyc2V0cy9ldWNqcC1tcy5hd2sKaW5kZXggMGM5Zjk0 ZDBmNC4uZjZhNjc0OGNlNSAxMDA2NDQKLS0tIGEvYWRtaW4vY2hhcnNldHMvZXVjanAtbXMu YXdrCisrKyBiL2FkbWluL2NoYXJzZXRzL2V1Y2pwLW1zLmF3awpAQCAtOTMsMTUgKzkzLDE3 IEBAIGZ1bmN0aW9uIHdyaXRlX2VudHJ5ICh1bmljb2RlKSB7CiAKIEVORCB7CiAgIHByaW50 ICIpKSkiOwotICBwcmludCAiICAobWFwYyAjJyhsYW1iZGEgKHgpIjsKKyAgcHJpbnQgIiAg KHNldHEgbWFwIjsKKyAgcHJpbnQgIiAgICAobWFwY2FyIjsKKyAgcHJpbnQgIgkobGFtYmRh ICh4KSI7CiAgIHByaW50ICIJICAgIChsZXQgKChjb2RlIChsb2dhbmQgKGNhciB4KSAjeDdG N0YpKSkiOwogICBwcmludCAiCSAgICAgIChpZiAoaW50ZWdlcnAgKGNkciB4KSkiOwotICBw cmludCAiCQkgIChzZXRjYXIgeCAoZGVjb2RlLWNoYXIgJ2phcGFuZXNlLWppc3gwMjA4IGNv ZGUpKSI7Ci0gIHByaW50ICIJCShzZXRjYXIgeCAoZGVjb2RlLWNoYXIgJ2phcGFuZXNlLWpp c3gwMjEyIGNvZGUpKSI7Ci0gIHByaW50ICIJCShzZXRjZHIgeCAoY2FkciB4KSkpKSkiOwot ICBwcmludCAiCW1hcCkiOworICBwcmludCAiCQkgIChjb25zIChkZWNvZGUtY2hhciAnamFw YW5lc2UtamlzeDAyMDggY29kZSkgKGNkciB4KSkiOworICBwcmludCAiCQkoY29ucyAoZGVj b2RlLWNoYXIgJ2phcGFuZXNlLWppc3gwMjEyIGNvZGUpIgorICBwcmludCAiCQkgICAgICAo Y2FkciB4KSkpKSkiOworICBwcmludCAiCW1hcCkpIjsKICAgcHJpbnQgIiAgKGRlZmluZS10 cmFuc2xhdGlvbi10YWJsZSAnZXVjanAtbXMtZGVjb2RlIG1hcCkiOwotICBwcmludCAiICAo bWFwYyAjJyhsYW1iZGEgKHgpIjsKKyAgcHJpbnQgIiAgKG1hcGMgKGxhbWJkYSAoeCkiOwog ICBwcmludCAiCSAgICAobGV0ICgodG1wIChjYXIgeCkpKSI7CiAgIHByaW50ICIJICAgICAg KHNldGNhciB4IChjZHIgeCkpIChzZXRjZHIgeCB0bXApKSkiOwogICBwcmludCAiCW1hcCki OwpkaWZmIC0tZ2l0IGEvZG9jL21pc2MvZW1hY3MtbWltZS50ZXhpIGIvZG9jL21pc2MvZW1h Y3MtbWltZS50ZXhpCmluZGV4IDQyYTc3NTBiOWEuLjJmMzhkY2Q0OTUgMTAwNjQ0Ci0tLSBh L2RvYy9taXNjL2VtYWNzLW1pbWUudGV4aQorKysgYi9kb2MvbWlzYy9lbWFjcy1taW1lLnRl eGkKQEAgLTkxNyw3ICs5MTcsNyBAQCBFbmNvZGluZyBDdXN0b21pemF0aW9uCiBAbGlzcAog KGFkZC10by1saXN0ICdnbnVzLW5ld3Nncm91cC12YXJpYWJsZXMgJ21tLWNvZGluZy1zeXN0 ZW0tcHJpb3JpdGllcykKIChzZXRxIGdudXMtcGFyYW1ldGVycwotICAgICAgKG5jb25jCisg ICAgICAoYXBwZW5kCiAgICAgICAgOzsgU29tZSBjaGFyc2V0cyBhcmUganVzdCBleGFtcGxl cyEKICAgICAgICAnKCgiXmNuXFwuIiA7OyBDaGluZXNlCiAgICAgICAgICAgKG1tLWNvZGlu Zy1zeXN0ZW0tcHJpb3JpdGllcwpkaWZmIC0tZ2l0IGEvbGlzcC9lbWFjcy1saXNwL2J5dGUt b3B0LmVsIGIvbGlzcC9lbWFjcy1saXNwL2J5dGUtb3B0LmVsCmluZGV4IDRmNzIyNTFhZWQu LjYyYjgyZTRmMzIgMTAwNjQ0Ci0tLSBhL2xpc3AvZW1hY3MtbGlzcC9ieXRlLW9wdC5lbAor KysgYi9saXNwL2VtYWNzLWxpc3AvYnl0ZS1vcHQuZWwKQEAgLTE1MDksNyArMTUwOSw3IEBA IGJ5dGUtY29tcGlsZS1zaWRlLWVmZmVjdC1hbmQtZXJyb3ItZnJlZS1vcHMKICAgICBieXRl LWN1cnJlbnQtYnVmZmVyIGJ5dGUtc3RhY2stcmVmKSkKIAogKGRlZmNvbnN0IGJ5dGUtY29t cGlsZS1zaWRlLWVmZmVjdC1mcmVlLW9wcwotICAobmNvbmMKKyAgKGFwcGVuZAogICAgJyhi eXRlLXZhcnJlZiBieXRlLW50aCBieXRlLW1lbXEgYnl0ZS1jYXIgYnl0ZS1jZHIgYnl0ZS1s ZW5ndGggYnl0ZS1hcmVmCiAgICAgIGJ5dGUtc3ltYm9sLXZhbHVlIGJ5dGUtZ2V0IGJ5dGUt Y29uY2F0MiBieXRlLWNvbmNhdDMgYnl0ZS1zdWIxIGJ5dGUtYWRkMQogICAgICBieXRlLWVx bHNpZ24gYnl0ZS1ndHIgYnl0ZS1sc3MgYnl0ZS1sZXEgYnl0ZS1nZXEgYnl0ZS1kaWZmIGJ5 dGUtbmVnYXRlCmRpZmYgLS1naXQgYS9saXNwL2ZyYW1lc2V0LmVsIGIvbGlzcC9mcmFtZXNl dC5lbAppbmRleCAxMGM2OTE0ZjUyLi4wNDYyZDc3NmMwIDEwMDY0NAotLS0gYS9saXNwL2Zy YW1lc2V0LmVsCisrKyBiL2xpc3AvZnJhbWVzZXQuZWwKQEAgLTM5NiwxNyArMzk2LDE3IEBA IGZyYW1lc2V0LXByb3AKIDs7IG9yLCBpZiB5b3UncmUgb25seSBjaGFuZ2luZyBhIGZldyBp dGVtcywKIDs7CiA7OyAgIChkZWZ2YXIgbXktZmlsdGVyLWFsaXN0Ci07OyAgICAgKG5jb25j ICcoKG15LXBhcmFtMSAuIDpuZXZlcikKLTs7ICAgICAgICAgICAgICAobXktcGFyYW0yIC4g bXktZmlsdGVyaW5nLWZ1bmN0aW9uKSkKLTs7ICAgICAgICAgICAgZnJhbWVzZXQtZmlsdGVy LWFsaXN0KQorOzsgICAgIChhcHBlbmQgJygobXktcGFyYW0xIC4gOm5ldmVyKQorOzsJCSAo bXktcGFyYW0yIC4gbXktZmlsdGVyaW5nLWZ1bmN0aW9uKSkKKzs7CSAgICAgICBmcmFtZXNl dC1maWx0ZXItYWxpc3QpCiA7OyAgICAgIk15IGJyaWVmIGN1c3RvbWl6ZWQgcGFyYW1ldGVy IGZpbHRlciBhbGlzdC4iKQogOzsKIDs7IGFuZCBwYXNzIGl0IHRvIHRoZSBGSUxURVIgYXJn IG9mIHRoZSBzYXZlL3Jlc3RvcmUgZnVuY3Rpb25zLAogOzsgQUxXQVlTIHRha2luZyBjYXJl IG9mIG5vdCBtb2RpZnlpbmcgdGhlIG9yaWdpbmFsIGxpc3RzOyBpZiB5b3UncmUKIDs7IGdv aW5nIHRvIGRvIGFueSBtb2RpZnlpbmcgb2YgbXktZmlsdGVyLWFsaXN0LCBwbGVhc2UgdXNl CiA7OwotOzsgICAobmNvbmMgJygobXktcGFyYW0xIC4gOm5ldmVyKSAuLi4pCi07OyAgICAg ICAgICAoY29weS1zZXF1ZW5jZSBmcmFtZXNldC1maWx0ZXItYWxpc3QpKQorOzsgICAoYXBw ZW5kICcoKG15LXBhcmFtMSAuIDpuZXZlcikgLi4uKQorOzsJICAgICAoY29weS1zZXF1ZW5j ZSBmcmFtZXNldC1maWx0ZXItYWxpc3QpKQogOzsKIDs7IE9uZSB0aGluZyB5b3Ugc2hvdWxk bid0IGZvcmdldCBpcyB0aGF0IHRoZXkgYXJlIGFsaXN0cywgc28gc2VhcmNoaW5nCiA7OyBp biB0aGVtIGlzIHNlcXVlbnRpYWwuICBJZiB5b3UganVzdCB3YW50IHRvIGNoYW5nZSB0aGUg ZGVmYXVsdCBvZgpAQCAtNDQ1LDcgKzQ0NSw3IEBAIGZyYW1lc2V0LXNlc3Npb24tZmlsdGVy LWFsaXN0CiAKIDs7OyMjI2F1dG9sb2FkCiAoZGVmdmFyIGZyYW1lc2V0LXBlcnNpc3RlbnQt ZmlsdGVyLWFsaXN0Ci0gIChuY29uYworICAoYXBwZW5kCiAgICAnKChiYWNrZ3JvdW5kLWNv bG9yICAgICAgICAgICAgLiBmcmFtZXNldC1maWx0ZXItc2FuaXRpemUtY29sb3IpCiAgICAg IChidWZmZXItbGlzdCAgICAgICAgICAgICAgICAgLiA6bmV2ZXIpCiAgICAgIChidWZmZXIt cHJlZGljYXRlICAgICAgICAgICAgLiA6bmV2ZXIpCmRpZmYgLS1naXQgYS9saXNwL2dudXMv Z251cy1zdW0uZWwgYi9saXNwL2dudXMvZ251cy1zdW0uZWwKaW5kZXggNmYzNjc2OTJkZC4u MzQxZjA0YWQ3NyAxMDA2NDQKLS0tIGEvbGlzcC9nbnVzL2dudXMtc3VtLmVsCisrKyBiL2xp c3AvZ251cy9nbnVzLXN1bS5lbApAQCAtMTUwMSw5ICsxNTAxLDkgQEAgZ251cy1zdW1tYXJ5 LW1vZGUtbGluZS1mb3JtYXQtYWxpc3QKIAogOzsgVGhpcyBpcyBoZXJlIHJhdGhlciB0aGFu IGluIGdudXMtYXJ0IGZvciBjb21waWxhdGlvbiByZWFzb25zLgogKGRlZnZhciBnbnVzLWFy dGljbGUtbW9kZS1saW5lLWZvcm1hdC1hbGlzdAotICAobmNvbmMgJygoP3cgKGdudXMtYXJ0 aWNsZS13YXNoLXN0YXR1cykgP3MpCi0JICAgKD9tIChnbnVzLWFydGljbGUtbWltZS1wYXJ0 LXN0YXR1cykgP3MpKQotCSBnbnVzLXN1bW1hcnktbW9kZS1saW5lLWZvcm1hdC1hbGlzdCkp CisgIChhcHBlbmQgJygoP3cgKGdudXMtYXJ0aWNsZS13YXNoLXN0YXR1cykgP3MpCisJICAg ICg/bSAoZ251cy1hcnRpY2xlLW1pbWUtcGFydC1zdGF0dXMpID9zKSkKKwkgIGdudXMtc3Vt bWFyeS1tb2RlLWxpbmUtZm9ybWF0LWFsaXN0KSkKIAogKGRlZnZhciBnbnVzLWxhc3Qtc2Vh cmNoLXJlZ2V4cCBuaWwKICAgIkRlZmF1bHQgcmVnZXhwIGZvciBhcnRpY2xlIHNlYXJjaCBj b21tYW5kLiIpCmRpZmYgLS1naXQgYS9saXNwL2xhbmd1YWdlL2phcGFuZXNlLmVsIGIvbGlz cC9sYW5ndWFnZS9qYXBhbmVzZS5lbAppbmRleCBkNzdlZmE0OGM5Li45YTk5MjQ1ZGZkIDEw MDY0NAotLS0gYS9saXNwL2xhbmd1YWdlL2phcGFuZXNlLmVsCisrKyBiL2xpc3AvbGFuZ3Vh Z2UvamFwYW5lc2UuZWwKQEAgLTgyLDkgKzgyLDcgQEAgJ2lzby0yMDIyLWpwLTIKIAkgKCN4 MDBBNiAuICN4RkZFNCkJOyBCUk9LRU4gTElORQkJRlVMTFdJRFRIIEJST0tFTiBMSU5FCiAJ ICkpKQogICAoZGVmaW5lLXRyYW5zbGF0aW9uLXRhYmxlICdqYXBhbmVzZS11Y3MtamlzLXRv LWNwOTMyLW1hcCBtYXApCi0gIChtYXBjICMnKGxhbWJkYSAoeCkgKGxldCAoKHRtcCAoY2Fy IHgpKSkKLQkJCShzZXRjYXIgeCAoY2RyIHgpKSAoc2V0Y2RyIHggdG1wKSkpCi0JbWFwKQor ICAoc2V0cSBtYXAgKG1hcGNhciAobGFtYmRhICh4KSAoY29ucyAoY2RyIHgpIChjYXIgeCkp KSBtYXApKQogICAoZGVmaW5lLXRyYW5zbGF0aW9uLXRhYmxlICdqYXBhbmVzZS11Y3MtY3A5 MzItdG8tamlzLW1hcCBtYXApKQogCiA7OyBVKzIwMTQgKEVNIERBU0gpIHZzIFUrMjAxNSAo SE9SSVpPTlRBTCBCQVIpCkBAIC0yNDEsOCArMjM5LDEwIEBAICdzaGlmdF9qaXMtMjAwNAog CSAoI3gyYjY1IC4gWyN4MDJFOSAjeDAyRTVdKQogCSAoI3gyYjY2IC4gWyN4MDJFNSAjeDAy RTldKSkpCiAgICAgICB0YWJsZSkKLSAgKGRvbGlzdCAoZWx0IG1hcCkKLSAgICAoc2V0Y2Fy IGVsdCAoZGVjb2RlLWNoYXIgJ2phcGFuZXNlLWppc3gwMjEzLTEgKGNhciBlbHQpKSkpCisg IChzZXRxIG1hcAorICAgICAgICAobWFwY2FyIChsYW1iZGEgKHgpIChjb25zIChkZWNvZGUt Y2hhciAnamFwYW5lc2UtamlzeDAyMTMtMSAoY2FyIHgpKQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIChjZHIgeCkpKQorICAgICAgICAgICAgICAgIG1hcCkpCiAgIChz ZXRxIHRhYmxlIChtYWtlLXRyYW5zbGF0aW9uLXRhYmxlLWZyb20tYWxpc3QgbWFwKSkKICAg KGRlZmluZS10cmFuc2xhdGlvbi10YWJsZSAnamlzeDAyMTMtdG8tdW5pY29kZSB0YWJsZSkK ICAgKGRlZmluZS10cmFuc2xhdGlvbi10YWJsZSAndW5pY29kZS10by1qaXN4MDIxMwpkaWZm IC0tZ2l0IGEvbGlzcC9sYW5ndWFnZS9sYW8tdXRpbC5lbCBiL2xpc3AvbGFuZ3VhZ2UvbGFv LXV0aWwuZWwKaW5kZXggYTIwYWVjZWU0Mi4uZmE0YzJmN2Y4OSAxMDA2NDQKLS0tIGEvbGlz cC9sYW5ndWFnZS9sYW8tdXRpbC5lbAorKysgYi9saXNwL2xhbmd1YWdlL2xhby11dGlsLmVs CkBAIC0xODMsNyArMTgzLDkgQEAgbGFvLWNvbXBvc2Utc3RyaW5nCiA7OyBTZW1pLXZvd2Vs LXNpZ24tbG8gYW5kIGxvd2VyIHZvd2VscyBhcmUgcHV0IHVuZGVyIHRoZSBsZXR0ZXIuCiAK IChkZWZjb25zdCBsYW8tdHJhbnNjcmlwdGlvbi1jb25zb25hbnQtYWxpc3QKLSAgKHNvcnQg Jyg7OyBzaW5nbGUgY29uc29uYW50cworICAoc29ydAorICAgKGNvcHktc2VxdWVuY2UKKwkn KDs7IHNpbmdsZSBjb25zb25hbnRzCiAJICAoImsiIC4gIuC6gSIpCiAJICAoImtoIiAuICLg uoIiKQogCSAgKCJxaCIgLiAi4LqEIikKQEAgLTIyMywxNCArMjI1LDE2IEBAIGxhby10cmFu c2NyaXB0aW9uLWNvbnNvbmFudC1hbGlzdAogCSAgKCJoeSIgLiBbIuC6q+C6jSJdKQogCSAg KCJobiIgLiBbIuC6q+C6mSJdKQogCSAgKCJobSIgLiBbIuC6q+C6oSJdKQotCSAgKQotCShm dW5jdGlvbiAobGFtYmRhICh4IHkpICg+IChsZW5ndGggKGNhciB4KSkgKGxlbmd0aCAoY2Fy IHkpKSkpKSkpCisJICApKQorICAgKGxhbWJkYSAoeCB5KSAoPiAobGVuZ3RoIChjYXIgeCkp IChsZW5ndGggKGNhciB5KSkpKSkpCiAKIChkZWZjb25zdCBsYW8tdHJhbnNjcmlwdGlvbi1z ZW1pLXZvd2VsLWFsaXN0CiAgICcoKCJyIiAuICLgurwiKSkpCiAKIChkZWZjb25zdCBsYW8t dHJhbnNjcmlwdGlvbi12b3dlbC1hbGlzdAotICAoc29ydCAnKCgiYSIgLiAi4LqwIikKKyAg KHNvcnQKKyAgIChjb3B5LXNlcXVlbmNlCisJJygoImEiIC4gIuC6sCIpCiAJICAoImFyIiAu ICLgurIiKQogCSAgKCJpIiAuICLgurQiKQogCSAgKCJpaSIgLiAi4Lq1IikKQEAgLTI1Nyw4 ICsyNjEsOCBAQCBsYW8tdHJhbnNjcmlwdGlvbi12b3dlbC1hbGlzdAogCSAgKCJhaSIgLiAi 4LuEIikKIAkgICgiZWkiIC4gIuC7gyIpCiAJICAoImFvIiAuIFsi4LuA4Lq74LqyIl0pCi0J ICAoImFNIiAuICLgurMiKSkKLQkoZnVuY3Rpb24gKGxhbWJkYSAoeCB5KSAoPiAobGVuZ3Ro IChjYXIgeCkpIChsZW5ndGggKGNhciB5KSkpKSkpKQorCSAgKCJhTSIgLiAi4LqzIikpKQor ICAgKGxhbWJkYSAoeCB5KSAoPiAobGVuZ3RoIChjYXIgeCkpIChsZW5ndGggKGNhciB5KSkp KSkpCiAKIDs7IE1hYS1zYWtvZCBpcyBwdXQgYXQgdGhlIHRhaWwuCiAoZGVmY29uc3QgbGFv LXRyYW5zY3JpcHRpb24tbWFhLXNha29kLWFsaXN0CmRpZmYgLS1naXQgYS9saXNwL2xhbmd1 YWdlL3RpYmV0YW4uZWwgYi9saXNwL2xhbmd1YWdlL3RpYmV0YW4uZWwKaW5kZXggZDMxY2Q1 Y2Q1Mi4uYmJkNDcyOWY2YyAxMDA2NDQKLS0tIGEvbGlzcC9sYW5ndWFnZS90aWJldGFuLmVs CisrKyBiL2xpc3AvbGFuZ3VhZ2UvdGliZXRhbi5lbApAQCAtMzI2LDcgKzMyNiw5IEBAIHRp YmV0YW4tcHJlY29tcG9zZWQtdHJhbnNjcmlwdGlvbi1hbGlzdAogCiAKIChkZWZjb25zdCB0 aWJldGFuLXN1YmpvaW5lZC10cmFuc2NyaXB0aW9uLWFsaXN0Ci0gIChzb3J0ICcoKCIrayIg IC4gIuC+kCIpCisgIChzb3J0CisgICAoY29weS1zZXF1ZW5jZQorCScoKCIrayIgIC4gIuC+ kCIpCiAJICAoIitraCIgLiAi4L6RIikKIAkgICgiK2ciICAuICLgvpIiKQogCSAgKCIrZ2gi IC4gIuC+kyIpCkBAIC0zNzEsOCArMzczLDggQEAgdGliZXRhbi1zdWJqb2luZWQtdHJhbnNj cmlwdGlvbi1hbGlzdAogCSAgKCIrVyIgLiAi4L66IikgOzsgZml4ZWQgZm9ybSBzdWJzY3Jp YmVkIFdBCiAJICAoIitZIiAuICLgvrsiKSA7OyBmaXhlZCBmb3JtIHN1YnNjcmliZWQgWUEK IAkgICgiK1IiIC4gIuC+vCIpIDs7IGZpeGVkIGZvcm0gc3Vic2NyaWJlZCBSQQotCSAgKQot CShsYW1iZGEgKHggeSkgKD4gKGxlbmd0aCAoY2FyIHgpKSAobGVuZ3RoIChjYXIgeSkpKSkp KQorCSAgKSkKKyAgIChsYW1iZGEgKHggeSkgKD4gKGxlbmd0aCAoY2FyIHgpKSAobGVuZ3Ro IChjYXIgeSkpKSkpKQogCiA7OzsKIDs7OyBhbGlzdCBmb3IgVGliZXRhbiBiYXNlIGNvbnNv bmFudCA8LT4gc3Viam9pbmVkIGNvbnNvbmFudCBjb252ZXJzaW9uLgpkaWZmIC0tZ2l0IGEv dGVzdC9zcmMvZm5zLXRlc3RzLmVsIGIvdGVzdC9zcmMvZm5zLXRlc3RzLmVsCmluZGV4IGM2 Y2VhZTRhMDAuLmI2NTU0M2E2NGIgMTAwNjQ0Ci0tLSBhL3Rlc3Qvc3JjL2Zucy10ZXN0cy5l bAorKysgYi90ZXN0L3NyYy9mbnMtdGVzdHMuZWwKQEAgLTQ5LDIxICs0OSwyMSBAQCBmbnMt dGVzdHMtbnJldmVyc2UKICAgKHNob3VsZC1lcnJvciAobnJldmVyc2UpKQogICAoc2hvdWxk LWVycm9yIChucmV2ZXJzZSAxKSkKICAgKHNob3VsZC1lcnJvciAobnJldmVyc2UgKG1ha2Ut Y2hhci10YWJsZSAnZm9vKSkpCi0gIChzaG91bGQgKGVxdWFsIChucmV2ZXJzZSAieHl6enki KSAieXp6eXgiKSkKLSAgKGxldCAoKEEgW10pKQorICAoc2hvdWxkIChlcXVhbCAobnJldmVy c2UgKGNvcHktc2VxdWVuY2UgInh5enp5IikpICJ5enp5eCIpKQorICAobGV0ICgoQSAodmVj dG9yKSkpCiAgICAgKG5yZXZlcnNlIEEpCiAgICAgKHNob3VsZCAoZXF1YWwgQSBbXSkpKQot ICAobGV0ICgoQSBbMF0pKQorICAobGV0ICgoQSAodmVjdG9yIDApKSkKICAgICAobnJldmVy c2UgQSkKICAgICAoc2hvdWxkIChlcXVhbCBBIFswXSkpKQotICAobGV0ICgoQSBbMSAyIDMg NF0pKQorICAobGV0ICgoQSAodmVjdG9yIDEgMiAzIDQpKSkKICAgICAobnJldmVyc2UgQSkK ICAgICAoc2hvdWxkIChlcXVhbCBBIFs0IDMgMiAxXSkpKQotICAobGV0ICgoQSBbMSAyIDMg NF0pKQorICAobGV0ICgoQSAodmVjdG9yIDEgMiAzIDQpKSkKICAgICAobnJldmVyc2UgQSkK ICAgICAobnJldmVyc2UgQSkKICAgICAoc2hvdWxkIChlcXVhbCBBIFsxIDIgMyA0XSkpKQot ICAobGV0KiAoKEEgWzEgMiAzIDRdKQorICAobGV0KiAoKEEgKHZlY3RvciAxIDIgMyA0KSkK IAkgKEIgKG5yZXZlcnNlIChucmV2ZXJzZSBBKSkpKQogICAgIChzaG91bGQgKGVxdWFsIEEg QikpKSkKIApAQCAtMTQ2LDEzICsxNDYsMTMgQEAgZm5zLXRlc3RzLWNvbGxhdGUtc3RyaW5n cwogOzsgSW52YWxpZCBVVEYtOCBzZXF1ZW5jZXMgc2hhbGwgYmUgaW5kaWNhdGVkLiAgSG93 IHRvIGNyZWF0ZSBzdWNoIHN0cmluZ3M/CiAKIChlcnQtZGVmdGVzdCBmbnMtdGVzdHMtc29y dCAoKQotICAoc2hvdWxkIChlcXVhbCAoc29ydCAnKDkgNSAyIC0xIDUgMyA4IDcgNCkgKGxh bWJkYSAoeCB5KSAoPCB4IHkpKSkKKyAgKHNob3VsZCAoZXF1YWwgKHNvcnQgKGxpc3QgOSA1 IDIgLTEgNSAzIDggNyA0KSAobGFtYmRhICh4IHkpICg8IHggeSkpKQogCQkgJygtMSAyIDMg NCA1IDUgNyA4IDkpKSkKLSAgKHNob3VsZCAoZXF1YWwgKHNvcnQgJyg5IDUgMiAtMSA1IDMg OCA3IDQpIChsYW1iZGEgKHggeSkgKD4geCB5KSkpCisgIChzaG91bGQgKGVxdWFsIChzb3J0 IChsaXN0IDkgNSAyIC0xIDUgMyA4IDcgNCkgKGxhbWJkYSAoeCB5KSAoPiB4IHkpKSkKIAkJ ICcoOSA4IDcgNSA1IDQgMyAyIC0xKSkpCi0gIChzaG91bGQgKGVxdWFsIChzb3J0ICdbOSA1 IDIgLTEgNSAzIDggNyA0XSAobGFtYmRhICh4IHkpICg8IHggeSkpKQorICAoc2hvdWxkIChl cXVhbCAoc29ydCAodmVjdG9yIDkgNSAyIC0xIDUgMyA4IDcgNCkgKGxhbWJkYSAoeCB5KSAo PCB4IHkpKSkKIAkJIFstMSAyIDMgNCA1IDUgNyA4IDldKSkKLSAgKHNob3VsZCAoZXF1YWwg KHNvcnQgJ1s5IDUgMiAtMSA1IDMgOCA3IDRdIChsYW1iZGEgKHggeSkgKD4geCB5KSkpCisg IChzaG91bGQgKGVxdWFsIChzb3J0ICh2ZWN0b3IgOSA1IDIgLTEgNSAzIDggNyA0KSAobGFt YmRhICh4IHkpICg+IHggeSkpKQogCQkgWzkgOCA3IDUgNSA0IDMgMiAtMV0pKQogICAoc2hv dWxkIChlcXVhbAogCSAgIChzb3J0CkBAIC0xNzIsNyArMTcyLDcgQEAgZm5zLXRlc3RzLWNv bGxhdGUtc29ydAogICA7OyBQdW5jdHVhdGlvbiBhbmQgd2hpdGVzcGFjZSBjaGFyYWN0ZXJz IGFyZSByZWxldmFudCBmb3IgUE9TSVguCiAgIChzaG91bGQKICAgIChlcXVhbAotICAgIChz b3J0ICcoIjExIiAiMTIiICIxIDEiICIxIDIiICIxLjEiICIxLjIiKQorICAgIChzb3J0IChs aXN0ICIxMSIgIjEyIiAiMSAxIiAiMSAyIiAiMS4xIiAiMS4yIikKIAkgIChsYW1iZGEgKGEg YikgKHN0cmluZy1jb2xsYXRlLWxlc3NwIGEgYiAiUE9TSVgiKSkpCiAgICAgJygiMSAxIiAi MSAyIiAiMS4xIiAiMS4yIiAiMTEiICIxMiIpKSkKICAgOzsgUHVuY3R1YXRpb24gYW5kIHdo aXRlc3BhY2UgY2hhcmFjdGVycyBhcmUgbm90IHRha2VuIGludG8gYWNjb3VudApAQCAtMTgw LDcgKzE4MCw3IEBAIGZucy10ZXN0cy1jb2xsYXRlLXNvcnQKICAgKHdoZW4gKGVxIHN5c3Rl bS10eXBlICd3aW5kb3dzLW50KQogICAgIChzaG91bGQKICAgICAgKGVxdWFsCi0gICAgICAo c29ydCAnKCIxMSIgIjEyIiAiMSAxIiAiMSAyIiAiMS4xIiAiMS4yIikKKyAgICAgIChzb3J0 IChsaXN0ICIxMSIgIjEyIiAiMSAxIiAiMSAyIiAiMS4xIiAiMS4yIikKICAgICAgICAgICAg IChsYW1iZGEgKGEgYikKICAgICAgICAgICAgICAgKGxldCAoKHczMi1jb2xsYXRlLWlnbm9y ZS1wdW5jdHVhdGlvbiB0KSkKICAgICAgICAgICAgICAgICAoc3RyaW5nLWNvbGxhdGUtbGVz c3AKQEAgLTE5MCw3ICsxOTAsNyBAQCBmbnMtdGVzdHMtY29sbGF0ZS1zb3J0CiAgIDs7IERp YWNyaXRpY3MgYXJlIGRpZmZlcmVudCBsZXR0ZXJzIGZvciBQT1NJWCwgdGhleSBzb3J0IGxl eGljb2dyYXBoaWNhbC4KICAgKHNob3VsZAogICAgKGVxdWFsCi0gICAgKHNvcnQgJygiw4Z2 YXIiICJBZ3VzdMOtbiIgIkFkcmlhbiIgIkVsaSIpCisgICAgKHNvcnQgKGxpc3QgIsOGdmFy IiAiQWd1c3TDrW4iICJBZHJpYW4iICJFbGkiKQogCSAgKGxhbWJkYSAoYSBiKSAoc3RyaW5n LWNvbGxhdGUtbGVzc3AgYSBiICJQT1NJWCIpKSkKICAgICAnKCJBZHJpYW4iICJBZ3VzdMOt biIgIkVsaSIgIsOGdmFyIikpKQogICA7OyBEaWFjcml0aWNzIGFyZSBzb3J0ZWQgYmV0d2Vl biBzaW1pbGFyIGxldHRlcnMgZm9yIG90aGVyIGxvY2FsZXMsCkBAIC0xOTgsNyArMTk4LDcg QEAgZm5zLXRlc3RzLWNvbGxhdGUtc29ydAogICAod2hlbiAoZXEgc3lzdGVtLXR5cGUgJ3dp bmRvd3MtbnQpCiAgICAgKHNob3VsZAogICAgICAoZXF1YWwKLSAgICAgIChzb3J0ICcoIsOG dmFyIiAiQWd1c3TDrW4iICJBZHJpYW4iICJFbGkiKQorICAgICAgKHNvcnQgKGxpc3QgIsOG dmFyIiAiQWd1c3TDrW4iICJBZHJpYW4iICJFbGkiKQogICAgICAgICAgICAgKGxhbWJkYSAo YSBiKQogICAgICAgICAgICAgICAobGV0ICgodzMyLWNvbGxhdGUtaWdub3JlLXB1bmN0dWF0 aW9uIHQpKQogICAgICAgICAgICAgICAgIChzdHJpbmctY29sbGF0ZS1sZXNzcApAQCAtMjEy LDcgKzIxMiw3IEBAIGZucy10ZXN0cy1zdHJpbmctdmVyc2lvbi1sZXNzcAogICAoc2hvdWxk IChub3QgKHN0cmluZy12ZXJzaW9uLWxlc3NwICJmb28yMDAwMC5wbmciICJmb28xMi5wbmci KSkpCiAgIChzaG91bGQgKHN0cmluZy12ZXJzaW9uLWxlc3NwICJmb28ucG5nIiAiZm9vMi5w bmciKSkKICAgKHNob3VsZCAobm90IChzdHJpbmctdmVyc2lvbi1sZXNzcCAiZm9vMi5wbmci ICJmb28ucG5nIikpKQotICAoc2hvdWxkIChlcXVhbCAoc29ydCAnKCJmb28xMi5wbmciICJm b28yLnBuZyIgImZvbzEucG5nIikKKyAgKHNob3VsZCAoZXF1YWwgKHNvcnQgKGxpc3QgImZv bzEyLnBuZyIgImZvbzIucG5nIiAiZm9vMS5wbmciKQogICAgICAgICAgICAgICAgICAgICAg ICAnc3RyaW5nLXZlcnNpb24tbGVzc3ApCiAgICAgICAgICAgICAgICAgICcoImZvbzEucG5n IiAiZm9vMi5wbmciICJmb28xMi5wbmciKSkpCiAgIChzaG91bGQgKHN0cmluZy12ZXJzaW9u LWxlc3NwICJmb28yIiAiZm9vMTIzNCIpKQpAQCAtNDMyLDkgKzQzMiw5IEBAIGZucy10ZXN0 cy1tYXBjYW4KICAgKHNob3VsZC1lcnJvciAobWFwY2FuKSkKICAgKHNob3VsZC1lcnJvciAo bWFwY2FuICMnaWRlbnRpdHkpKQogICAoc2hvdWxkLWVycm9yIChtYXBjYW4gIydpZGVudGl0 eSAobWFrZS1jaGFyLXRhYmxlICdmb28pKSkKLSAgKHNob3VsZCAoZXF1YWwgKG1hcGNhbiAj J2xpc3QgJygxIDIgMykpICcoMSAyIDMpKSkKKyAgKHNob3VsZCAoZXF1YWwgKG1hcGNhbiAj J2xpc3QgKGxpc3QgMSAyIDMpKSAnKDEgMiAzKSkpCiAgIDs7IGBtYXBjYW4nIGlzIGRlc3Ry dWN0aXZlCi0gIChsZXQgKChkYXRhICcoKGZvbykgKGJhcikpKSkKKyAgKGxldCAoKGRhdGEg KGxpc3QgKGxpc3QgJ2ZvbykgKGxpc3QgJ2JhcikpKSkKICAgICAoc2hvdWxkIChlcXVhbCAo bWFwY2FuICMnaWRlbnRpdHkgZGF0YSkgJyhmb28gYmFyKSkpCiAgICAgKHNob3VsZCAoZXF1 YWwgZGF0YSAgICAgICAgICAgICAgICAgICAgICcoKGZvbyBiYXIpIChiYXIpKSkpKSkKIAot LSAKMi4xNy4xCgo= --------------142A667DCA6DCB5AE96ED9CD-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects 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 To: Dmitry Gutov Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158967890715401 (code B ref 40671); Sun, 17 May 2020 01:29:01 +0000 Received: (at 40671) by debbugs.gnu.org; 17 May 2020 01:28:27 +0000 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 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 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) 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) 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 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) 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) 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> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Sat, 16 May 2020 18:28:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------3175E7D713E251357BAE1EB7" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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-- From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 May 2020 05:04: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 To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Dmitry Gutov Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.15896917832479 (code B ref 40671); Sun, 17 May 2020 05:04:01 +0000 Received: (at 40671) by debbugs.gnu.org; 17 May 2020 05:03:03 +0000 Received: from localhost ([127.0.0.1]:42089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaBS3-0000dv-IF for submit@debbugs.gnu.org; Sun, 17 May 2020 01:03:03 -0400 Received: from mout.web.de ([217.72.192.78]:54281) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaBS1-0000dR-0t for 40671@debbugs.gnu.org; Sun, 17 May 2020 01:03:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1589691736; bh=8wzubQLGgVGSfJ/Jndtxq2UYOkSQkKnhW35GT4ZFGDQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=hpn5r/ehwf1Vi9TDgPpavaVbyXwq/jp+TRXicCSwy1mERbLBIi0kQYzKY/153ryxA u3DZCRSXuIm9wHCMTMw7dp91ySfDL/wIKsNKjjeHj85FpOB0i12e8LGlcFAx3gUPLM bbZuMFHtr7IwDd0d8W6Tu0oQsWQ7IFaJ1H3nRY3s= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([188.98.100.187]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MD8BU-1jqjqF46Lk-00GaW0; Sun, 17 May 2020 07:02:16 +0200 From: Michael Heerdegen 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> Date: Sun, 17 May 2020 07:02:13 +0200 In-Reply-To: (Paul Eggert's message of "Sat, 16 May 2020 18:28:18 -0700") Message-ID: <877dxbm9wq.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:sEPRYfcIWuWIlNXk7NvD7AaUjoVJ7omo06p4ulpB2zbIoNKpffP jXKqjRTDMwXc+lglOtbsOhUThEKKlJoPLs5UP99Dat5AdATTpEayvsXwPUH46S7be681AlC Q7yFiZzhcJquE6UEkmAPZiE2XDZgDKfKVAAfEkVxSJWC8Soy/uEUMH1aP9wT5sEEJt6htpR PQy9FE0G8Y3QrXq3jT3Jw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:gKdt5GD7XiY=:O2PDtJrYWH+/pZf2BGmO+t RkzAjuWRpLObxZVJxM5bzT/PRvumpLu2mAwCvZhmTSbxS8Cjug7pJXseRFg3XWd2Yj5+SP9dr rRihq0oyor4STzEd6lCKAr5EDxdaFUfnUZB+Vlmx244u0dNRemDyO/iCLt4B/nVB5XNphmvVD w38+rZi7Ji79NmnzXSCu/Izwkqpcl9uYLwisQ/pzfoJZwkrQ23z2Ox7xggqv3VRl+uCKH+eFT 5wZzihQvINtoYg3G+TW1zHoJ8GzkPXKVOjpkx3BkeBpPKbrL1s+g/ic61nphef6Y6ykGc6dDs 2I5qQ4BMakJIc+pZRLMGeqFqnAiHECOLls+AD9TTFTMSZMfe6SGYl6ByUupXXCeTHqEMSAete k04hMux+90Ckh0yaCMHzmTjYXG+/NZSDyjm10DHmJmgIT9UJN6EDgpDJTV/JucjbZ7SPejvyz NN9BvR4i1xz3lmF4KuMSEjSJngg0SxSuGI7mg1BkA7ydmVFLfJkr99GmUN0Ylhaeo67Jygkxv HJD8oXiHRetiREmXIf08eCFXTaej3zDylX6bHqRn1G/p9gCpGfLLBdlOQt/6Kmsfw8gmLV6Xb fazr0Qon5EKTVTsk8c5KEDwBLmmLimsLwBdfrSpSIbVY+Z3N4O7KR7xDDplhk731uPFI27dn/ 3W2n0rnpn2YEKW/ivWv+LMYXjowYZeMx9PrmOBb/k8z4MuHg27OOsAnxbss0wBlyU3p7UrQpg U8crWDrx73IoW0JfqmEq/NxML9+ELV9C4FYf7wp5/ZqG/Z/L87Wn5Gpq2atbUCNISoPJ9duBQ soyLtkeaqGCBbDun5Rtg2+pvu51gNtvOxgpyY5YlRfhcMVakHUQO/CxNlZhhmvg0dS/MzuI9y 2+Y7MzYhnF6YGp95StkWSs9pt1tiPJxjai9GePxXc404GW/n6PVs8Pb+9HuCJ/otg1uagAbr3 jDjurCjF6RxC0TWOLyDJGIdSGNcLRZ3S3azekNt3Ic443qQYPpY/rdBrS+ha+h2n0QPtT78HB VtnVKSOaZGUWpHIEbo3t51TCRnvLm6lLdyNbynQyPe1fWfBbDX2bLPEl0zQh4n+zSuO+Qg1nk GTi1B2DEM8LCVsX6HpiVF0GdjC/rV/cOOTcOnnpiprsooEhiVrRXiTw63VO2RR3wzC0Kv1e+N G0REyKQkvoEXpibZ6GdqZAFiOGhzTx9muNXKzke9VCXEw7Mi8AxAcOTtsjY5HmIosVsKArRV/ JbxRiidX94rT7xc3C X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Eggert writes: > ... and symbol-name is one of the cases. I'm wondering about this one for a while, too. Is it that the resulting string is really like the "object is part of an evaluated program" cases, or is it just that modifying it has an unwanted side effect (changing the name of the symbol, and Emacs doesn't handle this correctly). I mean, you can modify a lot of objects in Emacs and that will cause trouble. We surely don't want to call them all constant or not safely mutable or whatever. How is the result of `symbol-name' different from these other cases? Is it only that the side effect/ mess is not visible from Lisp? Where do you draw the line? Yes, the hidden question is still what your definition of safely mutable is. Thanks, Michael. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 May 2020 09:45: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 To: Paul Eggert Cc: Michael Heerdegen , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158970864432085 (code B ref 40671); Sun, 17 May 2020 09:45:02 +0000 Received: (at 40671) by debbugs.gnu.org; 17 May 2020 09:44:04 +0000 Received: from localhost ([127.0.0.1]:42307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaFq0-0008LR-4T for submit@debbugs.gnu.org; Sun, 17 May 2020 05:44:04 -0400 Received: from mail237c50.megamailservers.eu ([91.136.10.247]:41408 helo=mail56c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaFpx-0008Ks-Ob for 40671@debbugs.gnu.org; Sun, 17 May 2020 05:44:02 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1589708623; bh=V8odF4KHUHIdnwCy1+0DkgR+rEv9GjL2z079Rxl85YE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ivzGbgCnPhmhmOTmHf7FQHY7eH5UZ920shF3lZUT4qL0ISHaDxjvt0zv75BA2X75R qmit34/E1Za8/lh1IKGzcZ+FQQzvTr8yxc1E01l8mX3BXasP0ugjMSR4OiFv/Gm1R5 0/3z2qNvgYR4tzy98hxpmV82NedwQTO6IjD3tKio= Feedback-ID: mattiase@acm.or Received: from stanniol.lan (c-4e4ae655.032-75-73746f71.bbcust.telenor.se [85.230.74.78]) (authenticated bits=0) by mail56c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 04H9hdlW001934; Sun, 17 May 2020 09:43:42 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <0e9e09ce-f129-b359-e9aa-5296708b0f45@cs.ucla.edu> Date: Sun, 17 May 2020 11:43:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FE4C211-A888-4696-893B-CE3C06901A27@acm.org> References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> <05BEF593-F16A-4DEE-98BC-653221F1F9EE@acm.org> <0e9e09ce-f129-b359-e9aa-5296708b0f45@cs.ucla.edu> X-Mailer: Apple Mail (2.3445.104.14) X-CTCH-RefID: str=0001.0A782F23.5EC106F4.005D:SCFSTAT68638221, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: -4.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=UqsdyN4B c=1 sm=1 tr=0 a=klNLuyVZdLUgl+K5Uafb2A==:117 a=klNLuyVZdLUgl+K5Uafb2A==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=ueNryGlU0QXi5fdAIB4A:9 a=CjuIK1q_8ugA:10 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 17 maj 2020 kl. 02.11 skrev Paul Eggert : > Thanks for sending that patch. Even if incomplete, it's better to not try to > modify constants so I installed the attached into master; it's derived from your > patch and supersedes my earlier (typ [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ucla.edu] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 17 maj 2020 kl. 02.11 skrev Paul Eggert : > Thanks for sending that patch. Even if incomplete, it's better to not = try to > modify constants so I installed the attached into master; it's derived = from your > patch and supersedes my earlier (typo-containing) patch about nconc. Thank you, and your resulting patch looks all right. As an extra check, = I verified that the AWK-generated files result in the same tables. The follow-up change reducing string and vector literal mutation also = looks fine. Just out of curiosity, how did you locate those instances? = By searching for calls to mutating functions or with an instrumented = Emacs? From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 May 2020 12:40: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 To: Paul Eggert Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158971916024615 (code B ref 40671); Sun, 17 May 2020 12:40:01 +0000 Received: (at 40671) by debbugs.gnu.org; 17 May 2020 12:39:20 +0000 Received: from localhost ([127.0.0.1]:42521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaIZb-0006Ow-PS for submit@debbugs.gnu.org; Sun, 17 May 2020 08:39:20 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:34774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaIZZ-0006Og-FU for 40671@debbugs.gnu.org; Sun, 17 May 2020 08:39:17 -0400 Received: by mail-wr1-f41.google.com with SMTP id y3so8623551wrt.1 for <40671@debbugs.gnu.org>; Sun, 17 May 2020 05:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FQmJYElsViZvtBvU+JNTib5HmXBhZ6XJO3qFw4dsRnk=; b=VCkJIkWj9yfeKQqdlEREZ2VXlW6Q6MvTdxV8RTjbGVAmGO2kZiWaRoLVuBtmc1xdgy SaGmK4pkJogdZhhXTrqUSJIwqA6l4c5zfIHFtzqvabvaGOi259sxwF0fX+18+SDTzLoQ uEvkaMt8iq8lJuJHiZJe6orsbfOfR6RMUM9wvddRkLXB6Ix0uJfPq3xQmzh95T24/Bty 2MEO+HVO3Y5x6rVY/XhCePwEwf9MXJ+Ai3rQWjPsUgIK6Bd5/HlRvEtgFOorB0IlrdFE gwD/G3/0iz7N10c79y54/MBcbGUXc4n1UuYX6Mpap4erluj7Eac4+TQ7Gi0Y2EYzF3HH RIfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FQmJYElsViZvtBvU+JNTib5HmXBhZ6XJO3qFw4dsRnk=; b=CU//f8iLzHYwONkIZslrUhMu19eG0dfI6UkVUXGoLbjH7kX4LEePHGBrt0WCLTMbxI RMlnt+0Gg+BF2dIC6JnyHQjTCJyUcfadQmJqVKjiYfzSVnzaXA0jVxlpgFAqqLwSPy7T 2pSRG/8cY5AOFa6ZRbTmjY4OLY/EQH74xNDxleusHH2Xi2TSS4kWM9DeMRIrxyzBPqwk YTEU8yX7GlbOjxANdZq36FQgvTsSP/0OCLQG8/+hb1WlPscWWnvQxF5iTZthhJEhRLON enOSHRA0VAQvfX1i+Yni76RxvU7isfkPDfji3d3g/4AUZCk6c8PO0PHdpRcUMLFEKosZ NWBA== X-Gm-Message-State: AOAM533s4t/3HuEgtMPTozTL7XXkq5CtGc453oqAboIBZlumZiHI4Lee tXnH8DaJd4d0BMF4gVlUADw= X-Google-Smtp-Source: ABdhPJxOjRAv38Ow1Uwv8I97I3Y1EKsuTYfpwwSKMrtaYZUeEZicNEFfjXaN43HYuoMu6ky3kxgvOA== X-Received: by 2002:a5d:46cf:: with SMTP id g15mr15362919wrs.276.1589719151526; Sun, 17 May 2020 05:39:11 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id f127sm12401748wmf.17.2020.05.17.05.39.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 May 2020 05:39:10 -0700 (PDT) References: <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> From: Dmitry Gutov Message-ID: <00ea7e60-9e47-9fce-52a7-cf66df6e180a@yandex.ru> Date: Sun, 17 May 2020 15:39:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 17.05.2020 04:28, Paul Eggert wrote: > 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. An existence of a technical term doesn't really cancel out the regular meaning of the word. >> 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. These are just two distinct points: 1. You seem to be trying to redefine the term "motable" as a way to avoid enumerating all possible cases. But since the meaning of the term is different from how it is understood in the English language, it should at least have a proper definition. But the said definition would have to cover the possible cases too. 2. symbol-name seems like something we don't have to explain specially. So if that's the only counter-example to "values that appear in expressions", or whichever phrase we chose, then we could as well just on the phrase and dispense with additional complications. Which would also make having a redefinition of the term "mutable" less relevant. > 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". There's an argument to be made that the name of the symbol 'cons is part of any expression or program that uses `cons'. >> 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 like that change, thank you. >> 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. OK, thank you. My intuition, though, that making cases like the one you just changed in emacs-lisp-mode-tests.el blow up at runtime will create a massive backward incompatibility. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 May 2020 16:22: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 To: Dmitry Gutov Cc: Michael Heerdegen , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158973250124514 (code B ref 40671); Sun, 17 May 2020 16:22:02 +0000 Received: (at 40671) by debbugs.gnu.org; 17 May 2020 16:21:41 +0000 Received: from localhost ([127.0.0.1]:44446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaM2j-0006NH-Sg for submit@debbugs.gnu.org; Sun, 17 May 2020 12:21:41 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaM2h-0006N1-Ts for 40671@debbugs.gnu.org; Sun, 17 May 2020 12:21:36 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6D2BB160052; Sun, 17 May 2020 09:21:30 -0700 (PDT) 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 i7EgSv9l7QVG; Sun, 17 May 2020 09:21:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8A1581600CC; Sun, 17 May 2020 09:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 XM2UkBRidNUx; Sun, 17 May 2020 09:21:29 -0700 (PDT) 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 366A7160052; Sun, 17 May 2020 09:21:29 -0700 (PDT) References: <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> <00ea7e60-9e47-9fce-52a7-cf66df6e180a@yandex.ru> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <0c35523b-9ce8-7612-2f58-ba425d96d83d@cs.ucla.edu> Date: Sun, 17 May 2020 09:21:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <00ea7e60-9e47-9fce-52a7-cf66df6e180a@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/17/20 5:39 AM, Dmitry Gutov wrote: > An existence of a technical term doesn't really cancel out the regular meaning > of the word. I continue to be skeptical that "constraints are always enforced" is the regular meaning of the word "constraints" in computing. Lots of constraints are not enforced in the computing world. Internet RFCs are a classic example: "Be liberal in what you accept" means "Don't enforce constraints". But again, we are straying from the point at hand, as the word "constraints" isn't used in the documentation when talking about mutability. > 1. You seem to be trying to redefine the term "motable" as a way to avoid > enumerating all possible cases. That is a normal practice for definitions, and this practice increases the utility of the documentation. The Emacs manual defines "string" without enumering all possible cases of strings (whether they come from the program text, or from reading input, or from symbol-name, etc.) because enumerating all cases would be bloat that would cause more harm than good. Similarly, the manual defines "mutable" without defining all possible cases of mutable objects. > 2. symbol-name seems like something we don't have to explain specially. I don't understand this comment. symbol-name is just an example. It's helpful to have an example or two, even if they're not absolutely required. > There's an argument to be made that the name of the symbol 'cons is part of any > expression or program that uses `cons'. Sure, and that argument is part of any bigger project to document more about mutability ("covering all the cases" in some way). This would not be a trivial project, and it's not something we have to do today. > My intuition, though, that making cases like the one you just changed in emacs-lisp-mode-tests.el blow up at runtime will create a massive backward incompatibility. I'm sure there are compatibility issues. But we already have those issues: an Elisp program that modifies a string constant is already "broken" in that it's making assumptions that have never been documented and are sometimes not true even now. Emacs used to have some runtime checking for this bug but it doesn't now, and when we reinstitute checking we will undoubtedly shake out some latent bugs in user code. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 May 2020 16:35: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 To: Michael Heerdegen Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Dmitry Gutov Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158973327726664 (code B ref 40671); Sun, 17 May 2020 16:35:01 +0000 Received: (at 40671) by debbugs.gnu.org; 17 May 2020 16:34:37 +0000 Received: from localhost ([127.0.0.1]:44459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaMFJ-0006vz-GM for submit@debbugs.gnu.org; Sun, 17 May 2020 12:34:37 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaMFH-0006jJ-9K for 40671@debbugs.gnu.org; Sun, 17 May 2020 12:34:35 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BD54C160052; Sun, 17 May 2020 09:34:29 -0700 (PDT) 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 XYRFhGxO7q-K; Sun, 17 May 2020 09:34:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0E2EB1600CC; Sun, 17 May 2020 09:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 ocungJ8EDMRn; Sun, 17 May 2020 09:34:28 -0700 (PDT) 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 C69C6160052; Sun, 17 May 2020 09:34:28 -0700 (PDT) References: <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> <877dxbm9wq.fsf@web.de> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: Date: Sun, 17 May 2020 09:34:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <877dxbm9wq.fsf@web.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/16/20 10:02 PM, Michael Heerdegen wrote: > you can modify a lot of objects in Emacs and that > will cause trouble. We surely don't want to call them all constant or > not safely mutable or whatever. We may not *want* to do that, but that's what we're doing now (with the two classes currently documented as "mutable objects" and "objects that you should not change"). And I don't see any easy way to change the documentation to draw the line that we'd like to draw (namely, between "mutable objects" and "objects that you cannot change") because that's not how Emacs works and changing Emacs's behavior will be nontrivial. At this point I suspect it'll be a better of our time to look into improving Emacs's behavior in this area, and worry about documentation wording later. From unknown Tue Jun 17 22:07:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40671: [DOC] modify literal objects Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 May 2020 16:39: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 To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Michael Heerdegen , 40671@debbugs.gnu.org Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158973352231202 (code B ref 40671); Sun, 17 May 2020 16:39:02 +0000 Received: (at 40671) by debbugs.gnu.org; 17 May 2020 16:38:42 +0000 Received: from localhost ([127.0.0.1]:44472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaMJG-00087B-1G for submit@debbugs.gnu.org; Sun, 17 May 2020 12:38:42 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jaMJ1-00086e-5I for 40671@debbugs.gnu.org; Sun, 17 May 2020 12:38:40 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A60E2160052; Sun, 17 May 2020 09:38:21 -0700 (PDT) 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 kGXFkE1DmKzm; Sun, 17 May 2020 09:38:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EA1AE1600CC; Sun, 17 May 2020 09:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 TcYdUA3tnDc6; Sun, 17 May 2020 09:38:20 -0700 (PDT) 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 BF80B160052; Sun, 17 May 2020 09:38:20 -0700 (PDT) References: <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> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> <87tv0nvztm.fsf@web.de> <05BEF593-F16A-4DEE-98BC-653221F1F9EE@acm.org> <0e9e09ce-f129-b359-e9aa-5296708b0f45@cs.ucla.edu> <8FE4C211-A888-4696-893B-CE3C06901A27@acm.org> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <05f90cb2-0e98-baa3-f2d4-292770afa45f@cs.ucla.edu> Date: Sun, 17 May 2020 09:38:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <8FE4C211-A888-4696-893B-CE3C06901A27@acm.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/17/20 2:43 AM, Mattias Engdeg=C3=A5rd wrote: > how did you locate those instances? By searching for calls to mutating = functions or with an instrumented Emacs? I built an instrumented Emacs. I am working on making it faster, since I = don't want the extra runtime checks to cost so much that people would prefer st= icking with the current, sometimes-crashing Emacs.