From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sun, 09 Sep 2012 06:00:11 +0300 Message-ID: <834nn7nbno.fsf@gnu.org> References: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> <87sjas4mc2.fsf@gnu.org> <83ipbomv6e.fsf@gnu.org> <2C45207ADF0E46BC98AF1B486695F632@us.oracle.com> <83fw6smti6.fsf@gnu.org> <9A8F619FD7584123A6319BD089E444E4@us.oracle.com> <83bohgmrdv.fsf@gnu.org> <83a9x0mq5e.fsf@gnu.org> <8E40573C868D4B339513A16A02588F5E@us.oracle.com> <837gs4mcqy.fsf@gnu.org> <852E534DA6A342708069D17B8C3C3DFF@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1347159647 16912 80.91.229.3 (9 Sep 2012 03:00:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Sep 2012 03:00:47 +0000 (UTC) Cc: 12314@debbugs.gnu.org, cyd@gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 09 05:00:49 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 1TAXlM-0006Ok-7Q for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Sep 2012 05:00:44 +0200 Original-Received: from localhost ([::1]:52942 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAXlI-00008r-L2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Sep 2012 23:00:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAXlG-00008l-2w for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 23:00:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TAXlE-0000F2-Ex for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 23:00:37 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAXlE-0000Ew-AP for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 23:00:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TAXle-0004Qg-Ci for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 23:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Sep 2012 03:01: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.134715963916993 (code B ref 12314); Sun, 09 Sep 2012 03:01:02 +0000 Original-Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 03:00:39 +0000 Original-Received: from localhost ([127.0.0.1]:49332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAXlG-0004Q0-Au for submit@debbugs.gnu.org; Sat, 08 Sep 2012 23:00:39 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:36837) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAXlD-0004Pn-Qq for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 23:00:36 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MA200D00ATE6D00@a-mtaout20.012.net.il> for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 06:00:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA200CARB08GGC0@a-mtaout20.012.net.il>; Sun, 09 Sep 2012 06:00:08 +0300 (IDT) In-reply-to: <852E534DA6A342708069D17B8C3C3DFF@us.oracle.com> X-012-Sender: halo1@inter.net.il 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:63986 Archived-At: > From: "Drew Adams" > Cc: , <12314@debbugs.gnu.org> > Date: Sat, 8 Sep 2012 15:26:04 -0700 > > > > > Why is it even necessary to talk about destructive > > > > modifications, if we are to advise to assign the result anyway? > > > > > > Not sure I understand the question. It is because these > > > operations can be destructive of list structure that we advise that. > > > > If you need to forget about the old value and assign the new one > > returned by 'delete', why does it matter that the modification was > > destructive? That pertains to the old value that you need to toss > > anyway. > > Perhaps we are miscommunicating. > > That general advice about assigning the variable is only a general guideline; it > is not absolute. You will NOT always want to assign the variable to the return > value. It all depends on what you want/need. Please describe the situations with using 'delete' when the old value will be wanted. (Please try to do that succinctly, because I get lost in your longish deliberations.) > The doc about these operations needs to describe what they do, and what they do > is typically destructive; that is, they typically modify list structure. > > The bit about variables here is only a heads-up about a classic gotcha, nothing > more. It is because we often have variables that are assigned/bound to the list > structure that we might be modifying that we should BE AWARE that these > operations do NOT do ANYTHING wrt variables. Being aware doesn't solve problems. To write reliable code, one needs to always do certain things. My understanding is that one must always assign the new value, because the old one is unpredictable in general. > > > If you have variables that point to some list structure > > > that you modify somehow, then it is up to you to ensure that > > > the variables point to what you want them to point to after > > > such modification. > > > > Variables that point to that list structure will point to something > > whose value is unpredictable, a.k.a. "garbage". It is enough to say > > that the old value is garbage and shouldn't be used, IMO. > > No. It all depends. Lisp programs that use list modification do so sometimes > for performance in calculating the new list, but more often they do so in order > to take advantage of SHARING list structure. > > (This too is something not so obvious to newbies - they can get the impression > that these operations are mainly about saving cycles in calculating the return > value.) But the manual should cater first and foremost to newbies. The rest will get the point when they read the detailed description of how the list is modified. > (setq a '(1 2 3 4)) > (setq b (cddr a)) > > a => (1 2 3 4) > b => (3 4) > > (delq 4 b) > > a => (1 2 3) > b => (3) > > The fact that modifying the list pointed to by `b' also modifies the list > pointed to by `a' is an advantage for certain kinds of programs. Without a > separate `setq' operation, the variables point to the same cons cells they > pointed to at the outset. And in some cases that is exactly what you want: you > want to remove the last link in the list that is shared by `a' and `b'. I fail to see the utility of this. Building code that relies on internal implementation details is never a good idea. But that's me; please don't bother to argue.