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: Sun, 9 Sep 2012 10:35:21 -0700 Message-ID: <38A3421174894E56BCF8C118983375B0@us.oracle.com> 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> <83627nnc2l.fsf@gnu.org> <83392rm840.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 1347212202 9285 80.91.229.3 (9 Sep 2012 17:36:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Sep 2012 17:36:42 +0000 (UTC) Cc: 12314@debbugs.gnu.org, cyd@gnu.org To: "'Eli Zaretskii'" , "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 09 19:36:42 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 1TAlR1-00040C-MH for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Sep 2012 19:36:39 +0200 Original-Received: from localhost ([::1]:53096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAlQy-0006wV-DC for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Sep 2012 13:36:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAlQv-0006wQ-D6 for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2012 13:36:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TAlQu-0007wi-5m for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2012 13:36:33 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAlQu-0007we-1Y for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2012 13:36:32 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TAlRN-0002FT-Kx for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2012 13:37:01 -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: Sun, 09 Sep 2012 17:37:01 +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.13472121728582 (code B ref 12314); Sun, 09 Sep 2012 17:37:01 +0000 Original-Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 17:36:12 +0000 Original-Received: from localhost ([127.0.0.1]:50514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAlQY-0002EM-MV for submit@debbugs.gnu.org; Sun, 09 Sep 2012 13:36:11 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:50554) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAlQV-0002ED-CP for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 13:36:08 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q89HZYsE015324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 9 Sep 2012 17:35:35 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q89HZXBA020640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Sep 2012 17:35:34 GMT Original-Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q89HZX4M004403; Sun, 9 Sep 2012 12:35:33 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 09 Sep 2012 10:35:33 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83392rm840.fsf@gnu.org> Thread-Index: Ac2OrqqGr0dEIeriS9CgegN8Aew5qQAAKcJA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:64011 Archived-At: > > >> Because it avoids memory allocation. I.e. 99% of the uses of > > >> delete/delq/nconc are simple optimizations. > > > > > > I meant "why does it matter FOR THE USER that the modification was > > > destructive?" Users don't care about optimizations, they > > > only care about performance. > > > > Because this optimization improves performance, > > But this optimization was already done. ?? > We don't tell users in the manuals about each and every > optimization we do to improve performance, do we? Eli, at the risk of butting in, I respectfully suggest that you might not be reading about this topic well enough or perhaps not thinking enough about it. The replies to you are now repetitive because there is not much more that can be said in response. Stefan is making the point that when programmers use `delete' or `delq' or `nconc' they often do so to improve the performance of their code. Which is true. We document what these functions do, including the fact that because of what they do they can often improve performance. And we mention caveats that users of such functions need to be aware of. This is not about any optimization that "we" do in implementing Emacs, i.e., something that Emacs does in its implementation, under the covers. This is about an intentional optimization that some Lisp programmers sometimes use in their own code. You can use destructive operations like `delete' to improve performance, but if you do so then you should be aware of some possible pitfalls. That's all.