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: Mon, 10 Sep 2012 08:21:57 -0700 Message-ID: <94A9E1848B7F45A0A185CA689FA724C4@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> <83pq5ulchr.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 1347290569 12146 80.91.229.3 (10 Sep 2012 15:22:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Sep 2012 15:22:49 +0000 (UTC) Cc: 12314@debbugs.gnu.org, cyd@gnu.org To: "'Stefan Monnier'" , "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 10 17:22:51 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 1TB5p3-0006di-U4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Sep 2012 17:22:50 +0200 Original-Received: from localhost ([::1]:44298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TB5p0-0004gZ-9z for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Sep 2012 11:22:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TB5op-0004bP-0V for bug-gnu-emacs@gnu.org; Mon, 10 Sep 2012 11:22:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TB5oh-0006To-7n for bug-gnu-emacs@gnu.org; Mon, 10 Sep 2012 11:22:34 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TB5oh-0006Tk-3i for bug-gnu-emacs@gnu.org; Mon, 10 Sep 2012 11:22:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TB5pF-0002eI-Rh for bug-gnu-emacs@gnu.org; Mon, 10 Sep 2012 11:23: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: Mon, 10 Sep 2012 15:23: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.134729056110154 (code B ref 12314); Mon, 10 Sep 2012 15:23:01 +0000 Original-Received: (at 12314) by debbugs.gnu.org; 10 Sep 2012 15:22:41 +0000 Original-Received: from localhost ([127.0.0.1]:52424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB5ov-0002dj-9I for submit@debbugs.gnu.org; Mon, 10 Sep 2012 11:22:41 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:22303) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB5os-0002dY-7O for 12314@debbugs.gnu.org; Mon, 10 Sep 2012 11:22:39 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8AFLxWa017919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 15:21:59 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8AFLwbE005500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 15:21:58 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8AFLwND005189; Mon, 10 Sep 2012 10:21:58 -0500 Original-Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Sep 2012 08:21:58 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac2PVBz9cOcdMt9dTSiaLx0Y+R1HQAAEEsog X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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:64050 Archived-At: > > My gripe was only about using the term "destructive > > modification", which muddies the waters without gaining anything. > > I don't know, to me "destructive modification" sounds like a > very clear term explaining the general kind of danger we're up > against (the kind that's summarized in Scheme by adding a "!" at > the end of the identifier). The term itself does not _explain_ the danger, but it does suggest some danger. Strictly speaking, "destructive modification" is redundant - all modification replaces one state by another: it destroys an old state and creates a new one. But Lisp being entre deux chaises (functional, imperative/procedural), and given the existence of similar-sounding Lisp functions such as `remove' and `delete', it is worth emphasizing the difference (for the doc of both `remove' and `delete'). For the non-modifying one, we point out explicitly that it is "non-destructive". For the modifying one, we point out explicitly that it modifies something, as a side effect, and we (conventionally, in Lisp jargon) call it "destructive". It's about the doc being not only correct but also more helpful. Sometimes a bit of redundancy has pedagogical merit. Sometimes redundancy is just noise to wade through. Here, specifically because of the "danger"/gotchas, it does not hurt to add "destructive", IMO. It is really the names of "non-destructive" functions such as `append' and `remove' that are misleading. They necessitate our taking pains to explain that no real modification takes place. Names that better suggest the declarative nature of such functions might be, say, `concatenation' and `all-but' (or `removed'). Names such as `append' and `remove' do not describe the result value of the function. Instead, they describe a modifying operation that might have nothing to do with the actual implementation (which is not so important here anyway), and they take emphasis away from what is important for a pure function: the return value. But such procedurally oriented naming is pretty common/traditional, even for applicative languages. And it tends toward shorter, simpler names.