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: Sun, 10 May 2020 19:33:40 -0700 (PDT) Message-ID: <19c29f91-b8d6-40bf-a3ee-42d8d84a1013@default> 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> 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="89304"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= To: Dmitry Gutov , Michael Heerdegen , Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 11 04:35:10 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 1jXyHe-000N89-Il for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 04:35:10 +0200 Original-Received: from localhost ([::1]:45226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXyHd-0004rs-L7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 May 2020 22:35:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXyHW-0004ri-CS for bug-gnu-emacs@gnu.org; Sun, 10 May 2020 22:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39283) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXyHW-0000wS-2x for bug-gnu-emacs@gnu.org; Sun, 10 May 2020 22:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jXyHW-0004Za-0S for bug-gnu-emacs@gnu.org; Sun, 10 May 2020 22:35: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: 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 Original-Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158916446717510 (code B ref 40671); Mon, 11 May 2020 02:35:01 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 11 May 2020 02:34:27 +0000 Original-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 Original-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 Original-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== Original-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 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 04B2RnFa063394; Mon, 11 May 2020 02:33:50 GMT Original-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 Original-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 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)] 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:180046 Archived-At: > >> 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.