From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#40671: [DOC] modify literal objects Date: Sun, 19 Apr 2020 17:24:40 -0700 Organization: UCLA Computer Science Department Message-ID: <99d7a8f9-7732-e1e3-414e-aabbea4433ac@cs.ucla.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="86604"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 40671@debbugs.gnu.org, ke.vigouroux@laposte.net To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 20 02:25:23 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 1jQKFW-000MRR-7t for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Apr 2020 02:25:22 +0200 Original-Received: from localhost ([::1]:55530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQKFV-0002Kn-6P for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Apr 2020 20:25:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50298 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQKFD-0002Is-IV for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 20:25:03 -0400 Original-Received: from Debian-exim by eggs1p.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQKFC-0003s6-TZ for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 20:25:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34705) by eggs1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQKFC-0003rc-HE for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 20:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jQKFC-0005EN-Bq for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 20:25:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158734229020086 (code B ref 40671); Mon, 20 Apr 2020 00:25:02 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 20 Apr 2020 00:24:50 +0000 Original-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 Original-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 Original-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) Original-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) Original-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 Original-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) Original-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) In-Reply-To: <87a7376nv9.fsf@web.de> Content-Language: en-US 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:178686 Archived-At: 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.