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: Tue, 28 Apr 2020 21:36:31 -0700 (PDT) Message-ID: 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> 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="26543"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , ke.vigouroux@laposte.net, 40671@debbugs.gnu.org, Richard Stallman To: Paul Eggert , Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 29 06:37: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 1jTeT8-0006nP-H9 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 Apr 2020 06:37:10 +0200 Original-Received: from localhost ([::1]:51548 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTeT7-0005Fk-2k for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 Apr 2020 00:37:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60948) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTeT1-0005Fe-0t for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2020 00:37:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTeT0-0006D5-Cl for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2020 00:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58855) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jTeT0-0006BM-0M for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2020 00:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jTeSz-0007Ln-UI for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2020 00:37:01 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158813501528243 (code B ref 40671); Wed, 29 Apr 2020 04:37:01 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 29 Apr 2020 04:36:55 +0000 Original-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 Original-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 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 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== Original-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 Original-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 Original-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 Original-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 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)] 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-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:179279 Archived-At: > > 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.