From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#40671: [DOC] modify literal objects Date: Mon, 20 Apr 2020 02:53:35 +0200 Message-ID: <87o8rnasfk.fsf@web.de> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="73633"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 20 02:54:59 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 1jQKiB-000J4m-E2 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Apr 2020 02:54:59 +0200 Original-Received: from localhost ([::1]:55744 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQKi9-0008KD-T8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Apr 2020 20:54:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57960 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQKhG-0008K3-J7 for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 20:54:03 -0400 Original-Received: from Debian-exim by eggs1p.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQKhG-0007Bp-12 for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 20:54:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34729) by eggs1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQKhF-0007AX-M3 for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 20:54:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jQKhF-0005uJ-Jz for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 20:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 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 Original-Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158734402922690 (code B ref 40671); Mon, 20 Apr 2020 00:54:01 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 00:53:49 +0000 Original-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 Original-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 Original-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 In-Reply-To: <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> (Paul Eggert's message of "Sun, 19 Apr 2020 17:24:40 -0700") X-Provags-ID: V03:K1:jTXp5c3jUp7HCPlE/kRvHrRV4NuYRZghaN8eaxCTU48lHxpZ4Qy HzXKQR2vpyPBfYfcSv4Wg/hW2uA15n9jzPJue28Y60PWDL8KPbyDC44QZz08T7bNRUiuI7J aicG3DBZDENQjSjMyJztTZOQOAbNm3HyYE5t4M2ZRK6cbkDPCAVU0DZpOqELDLkCbzd9jbL nt+q4TlGi7lwgeVZcTRqQ== 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+ 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:178690 Archived-At: 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.