From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#40671: [DOC] modify literal objects Date: Thu, 30 Apr 2020 22:16:42 -0700 (PDT) Message-ID: <89f0fa3b-5ba7-41d1-82d2-2aea8d9a6148@default> References: <87v9lzmdrw.fsf@laposte.net> <08c3b9ad-9c36-9dac-7f23-37886a034c0e@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="71281"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Kevin Vigouroux , 40671-done@debbugs.gnu.org To: Dmitry Gutov , Paul Eggert , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 01 07:18:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jUO3v-000IOQ-11 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 01 May 2020 07:18:11 +0200 Original-Received: from localhost ([::1]:53310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUO3t-00026v-Lp for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 01 May 2020 01:18:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55828) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUO3n-00026n-83 for bug-gnu-emacs@gnu.org; Fri, 01 May 2020 01:18:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUO3m-0001Dq-H6 for bug-gnu-emacs@gnu.org; Fri, 01 May 2020 01:18:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36536) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUO3m-0001Bw-4S for bug-gnu-emacs@gnu.org; Fri, 01 May 2020 01:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jUO3l-00016c-W8 for bug-gnu-emacs@gnu.org; Fri, 01 May 2020 01:18:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 40671-done@debbugs.gnu.org id=D40671.15883102284180 (code D ref 40671); Fri, 01 May 2020 05:18:01 +0000 Original-Received: (at 40671-done) by debbugs.gnu.org; 1 May 2020 05:17:08 +0000 Original-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 Original-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 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 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== Original-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 Original-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 Original-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 Original-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 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)] 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:179414 Archived-At: > > 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.