From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sat, 8 Sep 2012 08:48:53 -0700 Message-ID: <9A8F619FD7584123A6319BD089E444E4@us.oracle.com> References: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> <87sjas4mc2.fsf@gnu.org> <83ipbomv6e.fsf@gnu.org> <2C45207ADF0E46BC98AF1B486695F632@us.oracle.com> <83fw6smti6.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1347119391 11268 80.91.229.3 (8 Sep 2012 15:49:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Sep 2012 15:49:51 +0000 (UTC) Cc: 12314@debbugs.gnu.org, cyd@gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 08 17:49:53 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TANI2-0001Hg-8P for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Sep 2012 17:49:46 +0200 Original-Received: from localhost ([::1]:41489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TANHz-0001yj-0W for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Sep 2012 11:49:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TANHw-0001yb-6j for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 11:49:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TANHu-0007cs-Vw for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 11:49:40 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TANHu-0007co-SS for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 11:49:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TANII-0005wF-8B for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 11:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Sep 2012 15:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12314 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12314-submit@debbugs.gnu.org id=B12314.134711937122785 (code B ref 12314); Sat, 08 Sep 2012 15:50:02 +0000 Original-Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 15:49:31 +0000 Original-Received: from localhost ([127.0.0.1]:48786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANHm-0005vS-QF for submit@debbugs.gnu.org; Sat, 08 Sep 2012 11:49:31 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:24178) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANHk-0005vK-S9 for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 11:49:29 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q88Fn2pj004654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Sep 2012 15:49:03 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q88Fn2tc001563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 15:49:02 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q88Fn1Cs029839; Sat, 8 Sep 2012 10:49:01 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 08:49:01 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83fw6smti6.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac2N1W4zAQegyTZdSy6HyULHQ6VzOQAAYMuw X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:63948 Archived-At: > That for a list, assigning the result is not necessary. At least > that's my interpretation of what the manual says. No, that is incorrect. This is an old Lisp gotcha. It is one reason people often advise Lisp newbies not to start out by using destructive operations. They can be quite confusing, and you can run into trouble far from where a problem/bug is introduced. > > Keep reading the same section of the manual (section for `delete'): > > > > ;; If you want to change `l' reliably, > > ;; write `(setq l (delete '(2) l))'. > > My interpretation of "reliably" here is "without assuming that l is a > list". Is that a wrong interpretation? Yes, it is wrong. > > There is more explanation higher up in the same node, under `delq': > > 'delq' is not identical to 'delete', so assumptions that somethiong > described there is pertinent to 'delete' are unsafe. And how should > the reader know that she needs to read something under 'delq' to fully > understand what 'delete' does, anyway? The doc for `delete' sends you to the doc for `delq', where there is a good step-by-step illustration. The only difference between `delq' and `delete' is comparison by `eq' vs by `equal'. This is in fact a general thing for Lisp functions that are destructive of list structure. The manual describes it for `delq': When `delq' deletes elements from the front of the list, it does so simply by advancing down the list and returning a sublist that starts after those elements: (delq 'a '(a b c)) == (cdr '(a b c)) The point is not to confuse the _side effect_ of an operation (so-called "function") such as `delete' with its _return value_. The list targeted by the function might or might not be modified. The return value has the correct contents in all cases, and that is why you should generally set your variable to the return value, if you want that variable to reflect the result of the operation. The list structure is one thing. Your variable pointing to some list structure is another thing. If you want the variable to reflect the changed structure (list contents) in all cases, then set the variable value to the function's return value. In short, to reflect the _result_ of the operation, you need to set the variable to the returned result. Otherwise, it will not necessarily point to a list that has the correct contents. > I'm not sure who is missing what. All I'm saying is that the manual > seems to suggest that an explicit assignment is unnecessary, and yet > Chong did exactly that. If just "(delete 'foo bar)", with 'bar' a > list, is sometimes not enough, the manual should say when. And if it > is enough, why should we make the change in add-to-history? It is not enough, if you need the variable to reflect the updated list contents. It's about using the return value of the function vs depending on the "function" only for its side effect (i.e., not caring about what the variable points to after the operation). If we cared only about a particular list structure and not some variable that might point to it, then we might not bother to update the variable by setting it to the returned value. > IOW, it sounds like some kind of black magic is going on under the > hood, but the manual is too shy to talk about it. It shouldn't; doing > so could easily spread confusion. I'm not sure the code in question > was written as it was due to that confusion. It's not black magic, but it is about list structure and Lisp not being a (purely) functional language. Perhaps the node `Modifying Lists' should go into a little more detail about this; dunno. `delq' or `delete' is a great way to illustrate it, and we currently do that (for `delq'). Perhaps we should be more explicit about other list-modifying (i.e. destructive) operations having the same behavior, and generally advise setting any variable you care about to the returned value of the function.