From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 19:09:28 2012 Received: (at submit) by debbugs.gnu.org; 30 Aug 2012 23:09:28 +0000 Received: from localhost ([127.0.0.1]:58597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T7Drb-0006Cd-3k for submit@debbugs.gnu.org; Thu, 30 Aug 2012 19:09:27 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51239) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T7DrY-0006CW-Ms for submit@debbugs.gnu.org; Thu, 30 Aug 2012 19:09:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T7DqN-0005bJ-FH for submit@debbugs.gnu.org; Thu, 30 Aug 2012 19:08:12 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:54542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7DqN-0005bD-Bi for submit@debbugs.gnu.org; Thu, 30 Aug 2012 19:08:11 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7DqM-0006Ok-HD for bug-gnu-emacs@gnu.org; Thu, 30 Aug 2012 19:08:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T7DqL-0005ay-JF for bug-gnu-emacs@gnu.org; Thu, 30 Aug 2012 19:08:10 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:49438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7DqL-0005ar-C4 for bug-gnu-emacs@gnu.org; Thu, 30 Aug 2012 19:08:09 -0400 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 q7UN87eL009281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Aug 2012 23:08:08 GMT 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 q7UN86oK004885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Aug 2012 23:08:07 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7UN86EN024664 for ; Thu, 30 Aug 2012 18:08:06 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Aug 2012 16:08:06 -0700 From: "Drew Adams" To: Subject: 24.2.50; `add-to-history': use `setq' with `delete' Date: Thu, 30 Aug 2012 16:08:05 -0700 Message-ID: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac2HBE+yu4ZaRfw2SJmh1u1ByGJILw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) This line in `add-to-history': (if history-delete-duplicates (delete newelt history)) should be this: (if history-delete-duplicates (setq history (delete newelt history))) (Or for more clarity, use `when' instead of `if'.) I'm not 100% sure this is a problem, but it seems to be in a case I saw. And there seems to be no reason not to set `history' to the `delete' result here. In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-08-26 on MARVIN Bzr revision: 109788 dmantipov@yandex.ru-20120827041533-3cy7pdjdqz14o90c Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.6) --no-opt --enable-checking --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-3.0.9/include -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2' From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 10:32:46 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 14:32:46 +0000 Received: from localhost ([127.0.0.1]:48684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAM5W-0003I2-1W for submit@debbugs.gnu.org; Sat, 08 Sep 2012 10:32:46 -0400 Received: from mail-ie0-f172.google.com ([209.85.223.172]:55089) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAM5T-0003Hv-Sz for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 10:32:44 -0400 Received: by ieak13 with SMTP id k13so704045iea.3 for <12314@debbugs.gnu.org>; Sat, 08 Sep 2012 07:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=CdHU0U9rvmpaEhxBYrP6kpBarvdOHjDujX3n5VtR9tI=; b=b21MGc2uP7/H6iXicK72cuT/tNKPLC9uBVMA1pytU9Wtd/koTasIpfauuriOV7ldlS j6oqY/8APpxYQMI8s1oaaLjbeL5oxpSZwF5QbQd9mxoC4P43YUJEYh2hz3W5ssjJRRGN 09Y2xWbhHw7XPmUzrNqJ9jyTMCToZWtvcX3eK2HANPO0zYDQlZ502KmIqvotWBfF04TR dA/q08YvOnssws0Ql/UPIaRgYB4xVyYkkKgCLBphwhko1XcrBuuqAz8X+e9OrNwdzmcM QcJ64LFaK1kC0gl09HEAFu2Amtvxl7eo+Yg7ApBPKmVKM1/a0n+6FCpHFev91TF7tbi6 D6+Q== Received: by 10.50.195.164 with SMTP id if4mr1983607igc.20.1347114739263; Sat, 08 Sep 2012 07:32:19 -0700 (PDT) Received: from ulysses (cm162.gamma80.maxonline.com.sg. [202.156.80.162]) by mx.google.com with ESMTPS id i2sm2901980igl.8.2012.09.08.07.32.16 (version=SSLv3 cipher=OTHER); Sat, 08 Sep 2012 07:32:17 -0700 (PDT) From: Chong Yidong To: "Drew Adams" Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' References: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> Date: Sat, 08 Sep 2012 22:32:13 +0800 In-Reply-To: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> (Drew Adams's message of "Thu, 30 Aug 2012 16:08:05 -0700") Message-ID: <87sjas4mc2.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) "Drew Adams" writes: > This line in `add-to-history': > > (if history-delete-duplicates (delete newelt history)) > > should be this: > > (if history-delete-duplicates (setq history (delete newelt history))) Fixed, thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 10:32:57 2012 Received: (at control) by debbugs.gnu.org; 8 Sep 2012 14:32:57 +0000 Received: from localhost ([127.0.0.1]:48687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAM5h-0003IT-8Z for submit@debbugs.gnu.org; Sat, 08 Sep 2012 10:32:57 -0400 Received: from mail-ie0-f172.google.com ([209.85.223.172]:55089) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAM5f-0003Hv-NX for control@debbugs.gnu.org; Sat, 08 Sep 2012 10:32:56 -0400 Received: by mail-ie0-f172.google.com with SMTP id k13so704045iea.3 for ; Sat, 08 Sep 2012 07:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version:content-type; bh=97zsHeo++cPx15bKaD8ceL0nXmGNDjCytLf0W1pRV/Q=; b=sAGG1+01t5Sb0zNfkHTM1JzZfW5exqkpDUrVHgDZ8WVFVL2YBYN8FgUmWPlBoybQLc fPCSLjLBXeQjHWZS3ytZRj60z2cMUZcEhLjCJIYUqn6CN3y2C1C0SB4UHCecj6d9zB75 Tj82yk8zSJGjBWjuxDgPMA7J0M5sTDoiBQtH0JMDotcjs88YMXOjjaiXLSi394PTBt5O bK+fEAiX3SGMFK6PQLPcDrJ0i4THzNUW/wcwVE62ycnr3dAPPyswIx7pVZELUVUtqxI3 s3Bk6OCBpaLjxCT9V8n9paEp6B/CzRl4PkVn2SM+s+F0hIF74wvyD7jruO9xVIxLVUkt pDBA== Received: by 10.50.163.70 with SMTP id yg6mr2750814igb.30.1347114751815; Sat, 08 Sep 2012 07:32:31 -0700 (PDT) Received: from ulysses (cm162.gamma80.maxonline.com.sg. [202.156.80.162]) by mx.google.com with ESMTPS id n5sm5571507igw.13.2012.09.08.07.32.29 (version=SSLv3 cipher=OTHER); Sat, 08 Sep 2012 07:32:31 -0700 (PDT) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 12314 Date: Sat, 08 Sep 2012 22:32:27 +0800 Message-ID: <87bohgvb44.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) close 12314 thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 10:44:48 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 14:44:48 +0000 Received: from localhost ([127.0.0.1]:48719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAMHA-0003bb-Ci for submit@debbugs.gnu.org; Sat, 08 Sep 2012 10:44:48 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:54545) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAMH7-0003bP-Ju for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 10:44:46 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MA100D00CW3EG00@a-mtaout22.012.net.il> for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 17:43:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA100D47CX30E80@a-mtaout22.012.net.il>; Sat, 08 Sep 2012 17:43:51 +0300 (IDT) Date: Sat, 08 Sep 2012 17:43:53 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: <87sjas4mc2.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Chong Yidong Message-id: <83ipbomv6e.fsf@gnu.org> References: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> <87sjas4mc2.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Chong Yidong > Date: Sat, 08 Sep 2012 22:32:13 +0800 > Cc: 12314@debbugs.gnu.org > > "Drew Adams" writes: > > > This line in `add-to-history': > > > > (if history-delete-duplicates (delete newelt history)) > > > > should be this: > > > > (if history-delete-duplicates (setq history (delete newelt history))) > > Fixed, thanks. Does this mean the ELisp manual is in error? It says: -- Function: delete object sequence If `sequence' is a list, this function destructively removes all elements `equal' to OBJECT from SEQUENCE. ... If `sequence' is a vector or string, `delete' returns a copy of `sequence' with all elements `equal' to `object' removed. 'history' is a list, isn't it? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 10:57:49 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 14:57:49 +0000 Received: from localhost ([127.0.0.1]:48739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAMTl-0004kV-DK for submit@debbugs.gnu.org; Sat, 08 Sep 2012 10:57:49 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:37885) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAMTi-0004kN-FA for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 10:57:47 -0400 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 q88EvLSe004509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Sep 2012 14:57:21 GMT 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 q88EvKSx029714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 14:57:21 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q88EvKYB011425; Sat, 8 Sep 2012 09:57:20 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 07:57:20 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Chong Yidong'" References: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> <87sjas4mc2.fsf@gnu.org> <83ipbomv6e.fsf@gnu.org> Subject: RE: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sat, 8 Sep 2012 07:57:12 -0700 Message-ID: <2C45207ADF0E46BC98AF1B486695F632@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83ipbomv6e.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac2N0G+t6+aDiW28S72Wu/hzGjwvXwAAMCYg X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Does this mean the ELisp manual is in error? It says: > > -- Function: delete object sequence > If `sequence' is a list, this function destructively removes all > elements `equal' to OBJECT from SEQUENCE. > ... > If `sequence' is a vector or string, `delete' returns a copy of > `sequence' with all elements `equal' to `object' removed. > > 'history' is a list, isn't it? Yes, it is a list. What is your point/question? Keep reading the same section of the manual (section for `delete'): ;; If you want to change `l' reliably, ;; write `(setq l (delete '(2) l))'. There is more explanation higher up in the same node, under `delq': Don't assume that a variable which formerly held the argument LIST now has fewer elements, or that it still holds the original list! Instead, save the result of `delq' and use that. Most often we store the result back into the variable that held the original list: (setq flowers (delq 'rose flowers)) I would imagine that you already know this, so I'm likely missing something in your question. But if you don't already know this, or if you knew it but forgot it, there's no harm/shame in that. Does this help, or were you referring to something else? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 11:20:32 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 15:20:32 +0000 Received: from localhost ([127.0.0.1]:48768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAMpk-0005HV-Aw for submit@debbugs.gnu.org; Sat, 08 Sep 2012 11:20:32 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:61933) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAMph-0005HM-9e for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 11:20:31 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MA100D00E3HNR00@a-mtaout22.012.net.il> for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 18:19:59 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA100D09ELB67B0@a-mtaout22.012.net.il>; Sat, 08 Sep 2012 18:19:59 +0300 (IDT) Date: Sat, 08 Sep 2012 18:20:01 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: <2C45207ADF0E46BC98AF1B486695F632@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83fw6smti6.fsf@gnu.org> References: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> <87sjas4mc2.fsf@gnu.org> <83ipbomv6e.fsf@gnu.org> <2C45207ADF0E46BC98AF1B486695F632@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: <12314@debbugs.gnu.org> > Date: Sat, 8 Sep 2012 07:57:12 -0700 > > > Does this mean the ELisp manual is in error? It says: > > > > -- Function: delete object sequence > > If `sequence' is a list, this function destructively removes all > > elements `equal' to OBJECT from SEQUENCE. > > ... > > If `sequence' is a vector or string, `delete' returns a copy of > > `sequence' with all elements `equal' to `object' removed. > > > > 'history' is a list, isn't it? > > Yes, it is a list. What is your point/question? That for a list, assigning the result is not necessary. At least that's my interpretation of what the manual says. > 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? > 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? > I would imagine that you already know this, so I'm likely missing something in > your question. 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? 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 11:49:31 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 15:49:31 +0000 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 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 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 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 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 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 08:49:01 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> <87sjas4mc2.fsf@gnu.org> <83ipbomv6e.fsf@gnu.org> <2C45207ADF0E46BC98AF1B486695F632@us.oracle.com> <83fw6smti6.fsf@gnu.org> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 12:06:14 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:06:14 +0000 Received: from localhost ([127.0.0.1]:48806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANXx-0006Qq-S6 for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:06:14 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:49600) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANXv-0006Qg-GY for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:06:12 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MA100900GKB6W00@a-mtaout21.012.net.il> for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 19:05:46 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA1009QDGPL1Q60@a-mtaout21.012.net.il>; Sat, 08 Sep 2012 19:05:46 +0300 (IDT) Date: Sat, 08 Sep 2012 19:05:48 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: <9A8F619FD7584123A6319BD089E444E4@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83bohgmrdv.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> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <12314@debbugs.gnu.org> > Date: Sat, 8 Sep 2012 08:48:53 -0700 > > > 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. Then the manual should be corrected to state that much more explicitly than it does now. Perhaps it shouldn't even talk about destructive removal, as that will surely spread confusion. For me "destructive" means "in-place", and no amount of describing how 'delete' works internally will ever be able to countermand that. Besides, if all I need is a quick reminder about the semantics, I'm unlikely to read all the verbiage, let alone go up to read more under 'delq'. So the most important facts should be right there at the beginning, not hidden away under "note that" etc. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 12:20:26 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:20:26 +0000 Received: from localhost ([127.0.0.1]:48828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANli-0006pI-HJ for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:20:26 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:53008) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANlg-0006pB-Pi for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:20:25 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3XDghv0g0Kz4KK4M; Sat, 8 Sep 2012 18:19:58 +0200 (CEST) X-Auth-Info: U/JAb9lfNHrqII8g2WZOR0iV0fNHKgNNFWCVTI3plpY= Received: from igel.home (ppp-93-104-158-104.dynamic.mnet-online.de [93.104.158.104]) by mail.mnet-online.de (Postfix) with ESMTPA id 3XDght62ZxzbbgC; Sat, 8 Sep 2012 18:19:58 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id 665C5CA2A3; Sat, 8 Sep 2012 18:19:58 +0200 (CEST) From: Andreas Schwab To: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' 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> X-Yow: OVER the undertow! UNDER the overpass! Around the FUTURE and BEYOND REPAIR!! Date: Sat, 08 Sep 2012 18:19:58 +0200 In-Reply-To: <83bohgmrdv.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 08 Sep 2012 19:05:48 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eli Zaretskii writes: > Then the manual should be corrected to state that much more explicitly > than it does now. Perhaps it shouldn't even talk about destructive > removal, as that will surely spread confusion. For me "destructive" > means "in-place", and no amount of describing how 'delete' works > internally will ever be able to countermand that. Even if the element is not the first one, you always have to think about other references that may exist to the cons that is removed. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 12:25:48 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:25:48 +0000 Received: from localhost ([127.0.0.1]:48837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANqu-0006wX-9L for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:25:48 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:40116) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANqr-0006wQ-Nw for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:25:46 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q88GPIsl020659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Sep 2012 16:25:19 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q88GPGMj002283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 16:25:18 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q88GPGsm014423; Sat, 8 Sep 2012 11:25:16 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 09:25:16 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" 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> Subject: RE: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sat, 8 Sep 2012 09:25:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83bohgmrdv.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac2N28/2PSEZZ0SVQcSP8j8TS5JvAAAACXQw X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > It is not enough, if you need the variable to reflect the > > updated list contents. > > Then the manual should be corrected to state that much more explicitly > than it does now. Perhaps it shouldn't even talk about destructive > removal, as that will surely spread confusion. For me "destructive" > means "in-place", and no amount of describing how 'delete' works > internally will ever be able to countermand that. Besides, if all I > need is a quick reminder about the semantics, I'm unlikely to read all > the verbiage, let alone go up to read more under 'delq'. So the most > important facts should be right there at the beginning, not hidden > away under "note that" etc. Go for it. I suggest mentioning something like this in node `Modifying Lists' (and then cross-ref'ing that node from other nodes about functions that are destructive of list structure): Typically, you want a variable whose value is a list to reflect the result of any destructive operation on that list. To achieve that, set the variable value to the value returned by that operation. The reason for this is that operations that modify list structure do not also update any variables that might point to such structure. They are concerned only with changing list structure. Then give the `delq' example as an illustration of this. Point out why the variable's value no longer reflects the updated list content. (Perhaps even use a cons-cell diagram to illustrate.) 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: (setq sample-list '(a b c (4))) => (a b c (4)) (delq 'a sample-list) => (b c (4)) sample-list => (a b c (4)) Mention explicitly that the same thing is involved with *ALL* list-modification operations. The only things guaranteed by such operations are (a) the modification of the list structure takes place as advertised, and (b) the return value reflects the modified list structure correctly. So if you want a variable to reflect the list correctly as modified then set its value to the return value of the modification function. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 12:33:02 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:33:03 +0000 Received: from localhost ([127.0.0.1]:48847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANxu-00077W-KG for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:33:02 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:34544) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANxr-000777-JV for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:33:01 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MA100700HURNJ00@a-mtaout20.012.net.il> for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 19:32:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA1007H6HY29H90@a-mtaout20.012.net.il>; Sat, 08 Sep 2012 19:32:26 +0300 (IDT) Date: Sat, 08 Sep 2012 19:32:29 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83a9x0mq5e.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> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <12314@debbugs.gnu.org> > Date: Sat, 8 Sep 2012 09:25:08 -0700 > > Go for it. I suggest mentioning something like this in node `Modifying Lists' > (and then cross-ref'ing that node from other nodes about functions that are > destructive of list structure): Why is it even necessary to talk about destructive modifications, if we are to advise to assign the result anyway? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 12:33:32 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:33:32 +0000 Received: from localhost ([127.0.0.1]:48850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANyN-00078E-Uf for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:33:32 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:49901) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANyM-000786-5h for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:33:30 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MA100C00HUTAF00@a-mtaout23.012.net.il> for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 19:33:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA100CGKHZ43U70@a-mtaout23.012.net.il>; Sat, 08 Sep 2012 19:33:04 +0300 (IDT) Date: Sat, 08 Sep 2012 19:33:07 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: X-012-Sender: halo1@inter.net.il To: Andreas Schwab Message-id: <838vckmq4c.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> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Andreas Schwab > Cc: Drew Adams , 12314@debbugs.gnu.org, cyd@gnu.org > Date: Sat, 08 Sep 2012 18:19:58 +0200 > > Eli Zaretskii writes: > > > Then the manual should be corrected to state that much more explicitly > > than it does now. Perhaps it shouldn't even talk about destructive > > removal, as that will surely spread confusion. For me "destructive" > > means "in-place", and no amount of describing how 'delete' works > > internally will ever be able to countermand that. > > Even if the element is not the first one, you always have to think about > other references that may exist to the cons that is removed. Sorry, I'm not sure how this is related. Please elaborate. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 12:36:37 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:36:37 +0000 Received: from localhost ([127.0.0.1]:48856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAO1M-0007CR-H3 for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:36:36 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:49964) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAO1K-0007CI-8H for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:36:34 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q88Ga7m2025437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Sep 2012 16:36:08 GMT 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 q88Ga6CU023391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 16:36:07 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q88Ga66K013496; Sat, 8 Sep 2012 11:36:06 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 09:36:06 -0700 From: "Drew Adams" To: "'Andreas Schwab'" , "'Eli Zaretskii'" 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> Subject: RE: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sat, 8 Sep 2012 09:35:57 -0700 Message-ID: <60F244B0F8424BD6B776F2F8012D9052@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac2N3dEoseLH+oUiRRC3xxbjT9APkAAAMJtw X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > Then the manual should be corrected to state that much more > > explicitly than it does now. Perhaps it shouldn't even talk > > about destructive removal, as that will surely spread > > confusion. For me "destructive" means "in-place", and no > > amount of describing how 'delete' works internally will ever > > be able to countermand that. > > Even if the element is not the first one, you always have to > think about other references that may exist to the cons that > is removed. Exactly. That too merits an explicit mention. That is an even more insidious source of hard-to-find bugs. There is no harm in driving this point home, even at the risk of some repetition. Destructive operations should not be used without extra care. It is a gotcha that newbies sometimes learn the hard way. In particular, thinking that such operations are only about performance, and understanding that they can be more performant, newbies sometimes start using them right off the bat (premature optimization). And because the gotchas only surface in some situations, they don't necessarily notice problems right away. IIRC, the Common Lisp manual was pretty good at essentially warning readers not to use destructive operations unless they really understand them well. I don't recall just what was said, though. A simple guideline to set your variable to the list returned by such an operation will go a long way, I think. But we should of course explain why also. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 12:43:40 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:43:40 +0000 Received: from localhost ([127.0.0.1]:48862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAO8B-0007Np-SQ for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:43:40 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:16795) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAO88-0007Nh-H1 for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:43:37 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q88Gh98A028646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Sep 2012 16:43:10 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q88Gh8AE026944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 16:43:09 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q88Gh8RL025554; Sat, 8 Sep 2012 11:43:08 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 09:43:08 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" 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> Subject: RE: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sat, 8 Sep 2012 09:42:59 -0700 Message-ID: <8E40573C868D4B339513A16A02588F5E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83a9x0mq5e.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac2N34+YUBThbqvUTEmQwPgrQrQIjAAAIAlg X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > 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. These operations are not concerned with any variables, period - they act only on list structure. 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. It all depends on what you want/need. (This is a bit like using pointers. A variable points to a particular cons cell. Modifying one or more cons cells in a chain might or might not change that particular cons cell or cells that its cdr points to. The variable continues to point to the same cons cell, but that cell might not still reflect the "list" that you expect it to reflect.) From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 12:51:20 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:51:20 +0000 Received: from localhost ([127.0.0.1]:48867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAOFc-0007YG-3Z for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:51:20 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:33575) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAOFY-0007Y7-Ql for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:51:18 -0400 Received: from ip-165-52-149-91.dialup.ice.net ([91.149.52.165] helo=rusty) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TAOF1-0000RR-Ll; Sat, 08 Sep 2012 18:50:45 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' 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> <838vckmq4c.fsf@gnu.org> X-Now-Playing: Winston Tong's _Theoretically Chinese_ Date: Sat, 08 Sep 2012 18:50:40 +0200 In-Reply-To: <838vckmq4c.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 08 Sep 2012 19:33:07 +0300") Message-ID: <87k3w47927.fsf@gnus.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1TAOF1-0000RR-Ll X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1347727845.58823@CHoYvTEyV7sKctDCtZw5Vw X-Spam-Status: No X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, Andreas Schwab X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eli Zaretskii writes: > Sorry, I'm not sure how this is related. Please elaborate. `delete' may modify the list, so other references into the list may get surprising results after you've modified it. The current doc string is kinda obscure, though. It stars with --- Delete by side effect any occurrences of ELT as a member of SEQ. --- which is like "err". Perhaps something like Delete any occurrences of ELT from SEQ. This operation may destructively modify SEQ. See `remove' for a non-destructive version. would be more readable. -- (domestic pets only, the antidote for overdose, milk.) http://lars.ingebrigtsen.no * Lars Magne Ingebrigtsen From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 12:55:07 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:55:07 +0000 Received: from localhost ([127.0.0.1]:48871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAOJG-0007dJ-TZ for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:55:07 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:20692) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAOJE-0007dB-44 for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:55:05 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q88GsbkI001343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Sep 2012 16:54:38 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q88Gsalk017704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 16:54:37 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q88GsaRF029541; Sat, 8 Sep 2012 11:54:36 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 09:54:35 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Andreas Schwab'" 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> <838vckmq4c.fsf@gnu.org> Subject: RE: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sat, 8 Sep 2012 09:54:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <838vckmq4c.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac2N36DhYm4sn6RJR02cAiOKV2JZ5wAAWflQ X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > Even if the element is not the first one, you always have > > to think about other references that may exist to the > > cons that is removed. > > Sorry, I'm not sure how this is related. Please elaborate. (Think pointers.) A variable stays pointed to the same cons cell - these operations do not change that. But they can change the relations among cons cells: which of them point to which others. (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 value of variable `a' was changed by changing the value of `b', because `b' points to a cons cell that is used in the list structure pointed to by `a'. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 13:07:28 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 17:07:28 +0000 Received: from localhost ([127.0.0.1]:48877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAOVE-0007u7-7t for submit@debbugs.gnu.org; Sat, 08 Sep 2012 13:07:28 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:48129) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAOV9-0007ty-VO for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 13:07:26 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3XDhl71B1yz4KK4M; Sat, 8 Sep 2012 19:06:58 +0200 (CEST) X-Auth-Info: RzgC3Cyv2/AUTGwZ4KSJC4u3pHIjQfXICccuhEwdDXo= Received: from igel.home (ppp-93-104-158-104.dynamic.mnet-online.de [93.104.158.104]) by mail.mnet-online.de (Postfix) with ESMTPA id 3XDhl66gF3zbbcT; Sat, 8 Sep 2012 19:06:58 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id 71B37CA2A3; Sat, 8 Sep 2012 19:06:58 +0200 (CEST) From: Andreas Schwab To: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' 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> <838vckmq4c.fsf@gnu.org> X-Yow: How's it going in those MODULAR LOVE UNITS?? Date: Sat, 08 Sep 2012 19:06:58 +0200 In-Reply-To: <838vckmq4c.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 08 Sep 2012 19:33:07 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eli Zaretskii writes: >> From: Andreas Schwab >> Cc: Drew Adams , 12314@debbugs.gnu.org, cyd@gnu.org >> Date: Sat, 08 Sep 2012 18:19:58 +0200 >> >> Eli Zaretskii writes: >> >> > Then the manual should be corrected to state that much more explicitly >> > than it does now. Perhaps it shouldn't even talk about destructive >> > removal, as that will surely spread confusion. For me "destructive" >> > means "in-place", and no amount of describing how 'delete' works >> > internally will ever be able to countermand that. >> >> Even if the element is not the first one, you always have to think about >> other references that may exist to the cons that is removed. > > Sorry, I'm not sure how this is related. Please elaborate. It's just a special case of this general behaviour. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 17:22:35 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 21:22:35 +0000 Received: from localhost ([127.0.0.1]:49133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TASU7-0005Kq-AX for submit@debbugs.gnu.org; Sat, 08 Sep 2012 17:22:35 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:40334) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TASU4-0005Kg-5S for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 17:22:33 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MA100A00V8U8Z00@a-mtaout20.012.net.il> for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 00:21:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA100ABEVCI1W40@a-mtaout20.012.net.il>; Sun, 09 Sep 2012 00:21:55 +0300 (IDT) Date: Sun, 09 Sep 2012 00:21:57 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: <8E40573C868D4B339513A16A02588F5E@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <837gs4mcqy.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> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <12314@debbugs.gnu.org> > Date: Sat, 8 Sep 2012 09:42:59 -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. > 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. > It all depends on what you want/need. You can never want/need the old value, because you cannot predict what it will be. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 18:26:47 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 22:26:47 +0000 Received: from localhost ([127.0.0.1]:49181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TATUE-0006l0-DK for submit@debbugs.gnu.org; Sat, 08 Sep 2012 18:26:46 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:41753) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TATUB-0006ks-Fi for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 18:26:45 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q88MQEUk006677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Sep 2012 22:26:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q88MQDGF028579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 22:26:14 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q88MQDhk009745; Sat, 8 Sep 2012 17:26:13 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 15:26:13 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" 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> Subject: RE: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sat, 8 Sep 2012 15:26:04 -0700 Message-ID: <852E534DA6A342708069D17B8C3C3DFF@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <837gs4mcqy.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac2OCAGFmJjsg5VbSAycEKdxis9qxwAAgMBQ X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > > 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. 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. All they do is modify list structure. We typically give them access to the list structure via the values of variables. But the operations have nothing to do with the variables themselves - they are completely unaware of the existence of any variables. Hence, IF you want your variable, and not just some particular list structure, to always be updated to reflect your modification, then that is a separate step that you must perform after modification: assign the variable to the resulting list structure that you want. This is not so obvious to newbies, just as fiddling with pointers is not obvious to a newbie to a language that has pointers. A function such as `add-to-history' or `add-to-list' is something quite different. Those functions act on a VARIABLE, whose value is a list. IOW, they are aware of the existence of a certain variable - they are passed the SYMBOL as argument, not just its value, and they make sure that the variable gets updated. The modification functions that operate only on lists have no awareness of any variables. They are not passed a variable as argument. Their job is simply to return a list value, possibly (typically) modifying existing list structure in the process. > > 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.) For such programs - which are IMO the typical and the strongest (most important) uses of list modification, what you call garbage is anything but. Consider the example I gave before: (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'. List structure can be shared among multiple variables, so that changes to the structure are seen by more than one - perhaps all. Each variable provides a different view of parts or all of the list structure. > > It all depends on what you want/need. > > You can never want/need the old value, because you cannot predict what > it will be. Not so. If you know `a' and `b' before the operation then you know them afterward as well. What `a' and `b' here do NOT care about is `4' or the cons that contains `4' in its car. To THEM it is now garbage - it is no longer part of the lists THEY point to. But some other variable, `c', might well care about (point to) that particular cons. E.g., (setq a '(1 2 3 4)) (setq b (cddr a)) (setq c (cdr b)) Here, `c' points to the last cons cell in `a' and `b'. After the `delq' operation, that cons cell is no longer part of the lists pointed to by `a' and `b'. But it is still pointed to by `c'. And in such programs it can also be the case that what is garbage to `a' and `b' now will later be important to them. IOW, these 3 lists/views might well be logically related and dynamically change in related ways. Removing the sublist `c' from `a' and `b' might be a temporary operation - that sublist might be added back later. And when it is added back it might no longer contain `4' - it might then be (42 19 "hike"). You get the point. It is probably easier to see all of this by looking at `setcar' and `setcdr'. For `delq' we do not necessarily want/need to expose exactly how the implementation works, other than to say what it does in general and point out that it might NOT modify any existing list structure in some cases. But for `setcar' and `setcdr' the behavior is transparent and simple. They always modify list structure, and in simple ways. Think of variables whose values are cons cells as pointers. List modification can move such pointers around. In the above case, the pointer from the cdr of the first cons of `b' to its second cons is changed to point to nil. That's all. And `b' is a sublist of `a', so now `a's value reflects the structure change also. That can be a very handy thing. Certain kinds of programs take advantage of this sharing. Others - most - do not. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 19:12:21 2012 Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 23:12:21 +0000 Received: from localhost ([127.0.0.1]:49203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAUCK-0007mj-IQ for submit@debbugs.gnu.org; Sat, 08 Sep 2012 19:12:20 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:51764) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAUCI-0007mc-E7 for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 19:12:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09Ld+Y//2dsb2JhbABEsEiDSYEIghUBAQQBViMQCzQSFBgNJIgcBboJkEQDozOBWIMF X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="197874621" Received: from 75-119-230-63.dsl.teksavvy.com (HELO pastel.home) ([75.119.230.63]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 08 Sep 2012 19:11:51 -0400 Received: by pastel.home (Postfix, from userid 20848) id 09F8258FC1; Sat, 8 Sep 2012 19:11:50 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Message-ID: 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> Date: Sat, 08 Sep 2012 19:11:50 -0400 In-Reply-To: <837gs4mcqy.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Sep 2012 00:21:57 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > 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? Because it avoids memory allocation. I.e. 99% of the uses of delete/delq/nconc are simple optimizations. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 22:51:42 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 02:51:42 +0000 Received: from localhost ([127.0.0.1]:49324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAXcb-0004Cx-UP for submit@debbugs.gnu.org; Sat, 08 Sep 2012 22:51:42 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:35313) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAXcZ-0004Cp-M8 for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 22:51:40 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MA200D00AIO3S00@a-mtaout20.012.net.il> for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 05:51:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA200CWBALAZU20@a-mtaout20.012.net.il>; Sun, 09 Sep 2012 05:51:11 +0300 (IDT) Date: Sun, 09 Sep 2012 05:51:14 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83627nnc2l.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> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Drew Adams , 12314@debbugs.gnu.org, cyd@gnu.org > Date: Sat, 08 Sep 2012 19:11:50 -0400 > > >> > 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? > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 08 23:00:39 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 03:00:39 +0000 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 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 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) 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) Date: Sun, 09 Sep 2012 06:00:11 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: <852E534DA6A342708069D17B8C3C3DFF@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams 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> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 02:29:55 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 06:29:55 +0000 Received: from localhost ([127.0.0.1]:49445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAb1n-0000nG-0Z for submit@debbugs.gnu.org; Sun, 09 Sep 2012 02:29:55 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:37752) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAb1j-0000n7-70 for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 02:29:52 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q896TMdn019472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 9 Sep 2012 06:29:22 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q896TL0P008833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Sep 2012 06:29:21 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q896TLuM031665; Sun, 9 Sep 2012 01:29:21 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 23:29:20 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" 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> <834nn7nbno.fsf@gnu.org> Subject: RE: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sat, 8 Sep 2012 23:29:10 -0700 Message-ID: <28FCC57844B14FBE8F4CD6B0B9BAE6B3@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <834nn7nbno.fsf@gnu.org> Thread-Index: Ac2ONzshdevvNTPJRx2aD5YJ0KNDOAAF9Inw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > 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. > > 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. Intentional list modification is not an implementation detail. That is, it concerns the implementation of your program, of course, but not the implementation of Lisp itself. You have to know what a given Lisp operation does (side effects) and what it returns, but not how it is implemented. My description of this area apparently did not help you. Perhaps someone else can do better. You might start here: (elisp) `Modifying Lists'. You might search there for "share|sharing". You might also google for, say, "lisp sharing list structure modification". Looking at some of the hits, I think several should be helpful. Here's one that might be another place to start: http://en.wikipedia.org/wiki/Lisp_(programming_language)#Shared_structure Perhaps you can imagine a complex program with a humongous graph structure (already you see some sharing), which is dynamically modified. Imagine different views (e.g., variables) into various parts of that structure. This kind of Lisp program is not uncommon in some applications. (The same could be done using Java or C or whatever, but Lisp is good for doing things with lists.) Lisp is not a purely functional language. You need not like that, and you are not forced to use `setf' etc. when programming in Lisp. But such operations are a part of Lisp, and they are used by some Lisp programs. They are not a mistake, but it is possible to make mistakes when using them. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 03:54:09 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 07:54:10 +0000 Received: from localhost ([127.0.0.1]:49507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAcLJ-0004PR-Lr for submit@debbugs.gnu.org; Sun, 09 Sep 2012 03:54:09 -0400 Received: from mail-iy0-f172.google.com ([209.85.210.172]:33209) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAcLH-0004PK-Vg for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 03:54:08 -0400 Received: by iabz21 with SMTP id z21so935630iab.3 for <12314@debbugs.gnu.org>; Sun, 09 Sep 2012 00:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=QtZZGDd5zcRwZRwh9aaiiP1m1Z5bKh1rUESBQ6D67nY=; b=Q1iCyKT9BsCPsSLXcREMqHlcvGDWN3QYc5Uynu//sMwQdbWp4QNYhKsP84/xke4eyt LbtDDlElQdG6R65QIK29Os8mAE+Fiy06DOSAjDhIzeCJGE9Km74imbcNqg4rSm3yMr9S NEH9c2JnR8y7Y0TzYarp0c+nEUt0oR1jj3ddMimuHuyX3fVwXI+VPvsH4NsQzyKe47v+ TKHHIYNQAFHWkmeVGY6RmMWvhOZ49aTAHCqckq1hhpvnJxEDV05O0mflECj9jg0M1K6u ddxeRNgsTqrxqtWHusyra07S+tfRhIqEC1G0xZb/N183ReVCcaCNgiibGs1OU5xmcwJE 4epg== Received: by 10.50.10.166 with SMTP id j6mr6065998igb.13.1347177219478; Sun, 09 Sep 2012 00:53:39 -0700 (PDT) Received: from ulysses ([155.69.172.88]) by mx.google.com with ESMTPS id a10sm11399451igd.1.2012.09.09.00.53.36 (version=SSLv3 cipher=OTHER); Sun, 09 Sep 2012 00:53:38 -0700 (PDT) From: Chong Yidong To: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' 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> <834nn7nbno.fsf@gnu.org> Date: Sun, 09 Sep 2012 15:53:34 +0800 In-Reply-To: <834nn7nbno.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Sep 2012 06:00:11 +0300") Message-ID: <87r4qbr5s1.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Eli Zaretskii writes: > 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. I modified the manual to hopefully make the situation clearer. In particular, the descriptions of delq and delete explicitly say that you typically ought to use the return value. The docstrings are harder, since they should be succinct. Here is what I suggest; WDYT? (delq ELT LIST) Delete by side effect occurrences of ELT as a member of LIST. Comparison is done with `eq'. Return the resulting list. More precisely, this function skips any occurrences of ELT at the front of LIST, then removes occurrences of ELT from the remaining sublist by modifying the list structure, then returns the resulting sublist. Therefore, write `(setq foo (delq element foo))' to be sure of changing the value of `foo'. (delete ELT SEQ) Delete occurrence of ELT as a member of SEQ. SEQ must be a sequence (i.e. a list, a vector, or a string). Comparison is done with `equal'. Return the resulting sequence. If SEQ is a list, this behaves like `delq', except that it compares with `equal' instead of `eq'. In particular, it may remove elements by altering the list structure. If SEQ is not a list, deletion is not a side effect; this function creates and returns a new sequence. Therefore, write `(setq foo (delete element foo))' to be sure of changing the value of `foo'. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 04:25:59 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 08:25:59 +0000 Received: from localhost ([127.0.0.1]:49542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAcq6-00057Q-Et for submit@debbugs.gnu.org; Sun, 09 Sep 2012 04:25:59 -0400 Received: from forward4h.mail.yandex.net ([84.201.186.22]:58631) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAcq1-00057G-Ox for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 04:25:56 -0400 Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward4h.mail.yandex.net (Yandex) with ESMTP id EF5AD1B20194; Sun, 9 Sep 2012 12:25:23 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 97ADF134014D; Sun, 9 Sep 2012 12:25:23 +0400 (MSK) Received: from 5x166x246x245.dynamic.spb.ertelecom.ru (5x166x246x245.dynamic.spb.ertelecom.ru [5.166.246.245]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id PMU0Nhto-PNUi8VYU; Sun, 9 Sep 2012 12:25:23 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1347179123; bh=Q2VL0VmhWTYuFQSHuaru++nYpJBCZUNi049dYuCPg5o=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: Content-Type:Content-Transfer-Encoding; b=ZGv/LSaq7vcyO5HaGhJ5OvfSXEs/SSBwMpgjte54JTrkIJNR+jd/Bm+eIkXsYotU9 0dsZaJEbGkSqWyf1b/2JQse+kMbaupk0RdZ0RiKJlqomg5DI5KP7tJRSphHjtWfNot N2GGpRkrX8hIt2yiKmWZPkFbe+yDMSBWW5DTY47U= Message-ID: <504C5275.7040609@yandex.ru> Date: Sun, 09 Sep 2012 12:25:25 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: cyd@gnu.org Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, eliz@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Chong Yidong writes: > Eli Zaretskii writes: > >> 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. > > I modified the manual to hopefully make the situation clearer. In > particular, the descriptions of delq and delete explicitly say that you > typically ought to use the return value. > > The docstrings are harder, since they should be succinct. Here is what > I suggest; WDYT? > > > (delq ELT LIST) > > ... > > Therefore, write `(setq foo (delq element foo))' to be sure of > changing the value of `foo'. I think the last sentence could be better: (a) the value of foo won't necessarily change, even if we do (setq ...), (b) our goal is for foo to have the correct value, some not changed one. How about this? Therefore, write `(setq foo (delq element foo))' to make sure that `foo' points to the result. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 10:44:34 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 14:44:34 +0000 Received: from localhost ([127.0.0.1]:50387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAikU-0006qF-0x for submit@debbugs.gnu.org; Sun, 09 Sep 2012 10:44:34 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:48656) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAikR-0006q8-VB for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 10:44:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09Ld+Y//2dsb2JhbABEsEiDSYEIghUBAQQBViMQCzQSFBgNJIgcBboJkEQDozOBWIMF X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="197901094" Received: from 75-119-230-63.dsl.teksavvy.com (HELO pastel.home) ([75.119.230.63]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 09 Sep 2012 10:44:01 -0400 Received: by pastel.home (Postfix, from userid 20848) id 8A4F258FC1; Sun, 9 Sep 2012 10:44:01 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Message-ID: 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> Date: Sun, 09 Sep 2012 10:44:01 -0400 In-Reply-To: <83627nnc2l.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Sep 2012 05:51:14 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> 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, Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 13:15:38 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 17:15:38 +0000 Received: from localhost ([127.0.0.1]:50502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAl6g-0001mE-G9 for submit@debbugs.gnu.org; Sun, 09 Sep 2012 13:15:38 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:43003) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAl6e-0001m4-9F for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 13:15:37 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MA300000EJNTD00@a-mtaout20.012.net.il> for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 20:14:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA3000EAEJU96B0@a-mtaout20.012.net.il>; Sun, 09 Sep 2012 20:14:18 +0300 (IDT) Date: Sun, 09 Sep 2012 20:14:23 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83392rm840.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> <83627nnc2l.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12314@debbugs.gnu.org, cyd@gnu.org > Date: Sun, 09 Sep 2012 10:44:01 -0400 > > >> 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 13:26:27 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 17:26:27 +0000 Received: from localhost ([127.0.0.1]:50508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAlH8-00020g-L6 for submit@debbugs.gnu.org; Sun, 09 Sep 2012 13:26:26 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:46210) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAlH5-00020Y-RI for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 13:26:25 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MA300000F20Z100@a-mtaout20.012.net.il> for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 20:25:52 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA3000RBF34UV10@a-mtaout20.012.net.il>; Sun, 09 Sep 2012 20:25:52 +0300 (IDT) Date: Sun, 09 Sep 2012 20:25:56 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: <87r4qbr5s1.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Chong Yidong Message-id: <831uibm7kr.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> <834nn7nbno.fsf@gnu.org> <87r4qbr5s1.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Chong Yidong > Cc: Drew Adams , 12314@debbugs.gnu.org > Date: Sun, 09 Sep 2012 15:53:34 +0800 > > Eli Zaretskii writes: > > > 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. > > I modified the manual to hopefully make the situation clearer. In > particular, the descriptions of delq and delete explicitly say that you > typically ought to use the return value. Thanks, the text is much better now. I still think the "destructive modification" part should be retired to later in the description, perhaps as notes, because it invokes mental models that get in the way of interpreting the text correctly. But I won't fight over it. > The docstrings are harder, since they should be succinct. Here is what > I suggest; WDYT? > > > (delq ELT LIST) > > Delete by side effect occurrences of ELT as a member of LIST. > Comparison is done with `eq'. Return the resulting list. > > More precisely, this function skips any occurrences of ELT at the > front of LIST, then removes occurrences of ELT from the remaining > sublist by modifying the list structure, then returns the resulting > sublist. > > Therefore, write `(setq foo (delq element foo))' to be sure of > changing the value of `foo'. I would remove the "by side effect" part, as it doesn't really add anything of importance, and OTOH runs a real risk of confusing the reader. Otherwise, I think this is fine. Thanks. > (delete ELT SEQ) > > Delete occurrence of ELT as a member of SEQ. > SEQ must be a sequence (i.e. a list, a vector, or a string). > Comparison is done with `equal'. Return the resulting sequence. > > If SEQ is a list, this behaves like `delq', except that it compares > with `equal' instead of `eq'. In particular, it may remove elements > by altering the list structure. > > If SEQ is not a list, deletion is not a side effect; this function > creates and returns a new sequence. > > Therefore, write `(setq foo (delete element foo))' > to be sure of changing the value of `foo'. This is also OK, except that I'd prefer an explicit description to a reference to 'delq' in the second paragraph. The corresponding text in the doc string of 'delq' is short enough, so there are no real savings in the reference, while the disadvantage of having to consult another doc string is real. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 13:36:12 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 17:36:12 +0000 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 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 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 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 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 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 09 Sep 2012 10:35:33 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Stefan Monnier'" 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> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -7.3 (-------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.3 (-------) > > >> 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 14:21:13 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 18:21:13 +0000 Received: from localhost ([127.0.0.1]:50541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAm89-0003D3-3o for submit@debbugs.gnu.org; Sun, 09 Sep 2012 14:21:13 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:59863) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAm85-0003Cu-Qt for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 14:21:11 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MA300100GZSDX00@a-mtaout20.012.net.il> for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 21:20:38 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA3001UZHM99M30@a-mtaout20.012.net.il>; Sun, 09 Sep 2012 21:20:33 +0300 (IDT) Date: Sun, 09 Sep 2012 21:20:38 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: <38A3421174894E56BCF8C118983375B0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83txv7kqh5.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> <83627nnc2l.fsf@gnu.org> <83392rm840.fsf@gnu.org> <38A3421174894E56BCF8C118983375B0@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: <12314@debbugs.gnu.org>, > Date: Sun, 9 Sep 2012 10:35:21 -0700 > > 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. How is this remark helpful? > 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. This is an entirely different issue. "Destructive modification" does not imply the optimization you (and evidently Stefan) are alluding to, at least not universally so, nor a possibility to piggy-back that to optimize application code. It just means that the original object is modified (a.k.a. "destroyed") in the process. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 15:47:14 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 19:47:15 +0000 Received: from localhost ([127.0.0.1]:50637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAnTN-0005Ay-2i for submit@debbugs.gnu.org; Sun, 09 Sep 2012 15:47:14 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:36010) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAnTK-0005Aq-HC for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 15:47:11 -0400 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 q89JkbH4003601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 9 Sep 2012 19:46:38 GMT 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 q89Jkb9I013118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Sep 2012 19:46:37 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q89Jka3d016056; Sun, 9 Sep 2012 14:46:36 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 09 Sep 2012 12:46:36 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" 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> <38A3421174894E56BCF8C118983375B0@us.oracle.com> <83txv7kqh5.fsf@gnu.org> Subject: RE: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sun, 9 Sep 2012 12:46:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83txv7kqh5.fsf@gnu.org> Thread-Index: Ac2Ot9GVTmjXqsCIRHSLngRLr6TX/QACdbIQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -7.3 (-------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.3 (-------) > > 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. > > How is this remark helpful? I am sincerely _trying_ to help you. I've tried to explain and give examples. I've pointed you to other explanations on line and elsewhere in the Elisp manual. And I've suggested that you take a bit more time to study and think about what you've read. And I would add, perhaps experiment. If my attempts to help do not help you or you do not appreciate them, sorry. This is really not that big a deal. Ask around. This is a common question and lots of people have explained it in various ways. Take your pick. > > 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. > > This is an entirely different issue. "Destructive modification" does > not imply the optimization you (and evidently Stefan) are alluding to, > at least not universally so, nor a possibility to piggy-back that to > optimize application code. It just means that the original object is > modified (a.k.a. "destroyed") in the process. To quote a famous person (you), I give up. I sincerely hope someone else helps you find what you're looking for. If not, maybe you will reread the thread or the manual at a later date and you will find it yourself. Sometimes that's all it takes for things to become clear. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 09 17:38:28 2012 Received: (at 12314) by debbugs.gnu.org; 9 Sep 2012 21:38:28 +0000 Received: from localhost ([127.0.0.1]:50731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TApD1-0007k8-KS for submit@debbugs.gnu.org; Sun, 09 Sep 2012 17:38:27 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:9299) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TApCz-0007k1-Uy for 12314@debbugs.gnu.org; Sun, 09 Sep 2012 17:38:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu0+4rxAc/2dsb2JhbABEsEiDSYEIghUBAQQBViMQCzQSFBgNJIgcBboJkEQDozOBWIMF X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="197920465" Received: from 184-175-16-28.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([184.175.16.28]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 09 Sep 2012 17:37:53 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 949BEAE1FC; Sun, 9 Sep 2012 17:37:53 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Message-ID: 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> Date: Sun, 09 Sep 2012 17:37:53 -0400 In-Reply-To: <83392rm840.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Sep 2012 20:14:23 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > 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? I don't understand the question: the user of delete/delq/nconc (the one reading their docstring or their texinfo doc) is the person reading/writing the code, and the optimization is the act of choosing delete over remove or delq over remq or nconc over append, which is exactly what the reader will want to know, I think. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 10 00:38:26 2012 Received: (at 12314) by debbugs.gnu.org; 10 Sep 2012 04:38:26 +0000 Received: from localhost ([127.0.0.1]:50976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAvlR-0000VI-Q4 for submit@debbugs.gnu.org; Mon, 10 Sep 2012 00:38:26 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:49598) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAvlK-0000V4-Dv for 12314@debbugs.gnu.org; Mon, 10 Sep 2012 00:38:22 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MA400D00A2ZTJ00@a-mtaout22.012.net.il> for 12314@debbugs.gnu.org; Mon, 10 Sep 2012 07:37:16 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA400DTZA62MU60@a-mtaout22.012.net.il>; Mon, 10 Sep 2012 07:37:14 +0300 (IDT) Date: Mon, 10 Sep 2012 07:37:20 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83pq5ulchr.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> <83627nnc2l.fsf@gnu.org> <83392rm840.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12314@debbugs.gnu.org, cyd@gnu.org > Date: Sun, 09 Sep 2012 17:37:53 -0400 > > >> > 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? > > I don't understand the question: the user of delete/delq/nconc (the one > reading their docstring or their texinfo doc) is the person > reading/writing the code, and the optimization is the act of choosing > delete over remove or delq over remq or nconc over append, which is > exactly what the reader will want to know, I think. See my other message: I think we are talking about 2 different things. My gripe was only about using the term "destructive modification", which muddies the waters without gaining anything. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 10 08:19:46 2012 Received: (at 12314) by debbugs.gnu.org; 10 Sep 2012 12:19:46 +0000 Received: from localhost ([127.0.0.1]:51543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB2xt-0003pV-OS for submit@debbugs.gnu.org; Mon, 10 Sep 2012 08:19:46 -0400 Received: from mx18.lb01.inode.at ([62.99.145.20]:8535 helo=mx.inode.at) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB2xn-0003pF-CA for 12314@debbugs.gnu.org; Mon, 10 Sep 2012 08:19:43 -0400 Received: from [91.119.101.188] (port=2053 helo=iznogoud.viz) by smartmx-18.inode.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TB2xC-0002Qe-TF; Mon, 10 Sep 2012 14:19:03 +0200 Received: from wolfgang by iznogoud.viz with local (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TB2xA-0000wV-4B; Mon, 10 Sep 2012 14:19:00 +0200 From: Wolfgang Jenkner To: "Drew Adams" Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Mon, 10 Sep 2012 13:54:40 +0200 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> Message-ID: <85zk4yoyto.fsf@iznogoud.viz> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, 'Eli Zaretskii' , cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.3 (--) On Sun, Sep 09 2012, Drew Adams wrote: >> 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. > > Consider the example I gave before: > > (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) Though using `delete' and friends this way would have unpredictable results in ANSI Common Lisp[1] or Scheme (delete! in srfi1[2]), hence may be regarded as questionable programming style in Emacs Lisp as well, which I understand is Eli's point. The following should work in both CL (except for the missing DEFVARs) and Emacs Lisp, but sort of defeats the point about easy sharing ;-) (setq a (list 1 2 3 4)) (setq b (cddr a)) (setf (cddr a) (setq b (delete 4 b))) [1] http://www.lispworks.com/documentation/HyperSpec/Body/f_rm_rm.htm#delete http://www.lispworks.com/documentation/HyperSpec/Issues/iss293_w.htm [2] http://srfi.schemers.org/srfi-1/srfi-1.html#LinearUpdateProcedures Wolfgang From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 10 09:00:05 2012 Received: (at 12314) by debbugs.gnu.org; 10 Sep 2012 13:00:05 +0000 Received: from localhost ([127.0.0.1]:51597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB3au-00062W-HJ for submit@debbugs.gnu.org; Mon, 10 Sep 2012 09:00:04 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:43770) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB3as-00061y-59 for 12314@debbugs.gnu.org; Mon, 10 Sep 2012 09:00:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu0+4rxAc/2dsb2JhbABEsEiDSYEIghUBAQQBVhYNBQsLNBIUGA0kiBwFugmQRAOjM4FYgwU X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="197956411" Received: from 184-175-16-28.dsl.teksavvy.com (HELO pastel.home) ([184.175.16.28]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 Sep 2012 08:59:26 -0400 Received: by pastel.home (Postfix, from userid 20848) id 6CCCF59219; Mon, 10 Sep 2012 08:59:26 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Message-ID: 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> Date: Mon, 10 Sep 2012 08:59:26 -0400 In-Reply-To: <83pq5ulchr.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 10 Sep 2012 07:37:20 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > See my other message: I think we are talking about 2 different > things. 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). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 10 11:01:43 2012 Received: (at 12314) by debbugs.gnu.org; 10 Sep 2012 15:01:43 +0000 Received: from localhost ([127.0.0.1]:52352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB5Uc-00028p-0z for submit@debbugs.gnu.org; Mon, 10 Sep 2012 11:01:43 -0400 Received: from relais.videotron.ca ([24.201.245.36]:12420) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB5UX-00028g-VA for 12314@debbugs.gnu.org; Mon, 10 Sep 2012 11:01:39 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from fmsmemgm.homelinux.net ([24.201.208.110]) by VL-VM-MR001.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MA500E4K31QIU00@VL-VM-MR001.ip.videotron.ca> for 12314@debbugs.gnu.org; Mon, 10 Sep 2012 11:01:02 -0400 (EDT) Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 1BF52AE200; Mon, 10 Sep 2012 11:01:01 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Message-id: 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> Date: Mon, 10 Sep 2012 11:01:01 -0400 In-reply-to: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) >> See my other message: I think we are talking about 2 different >> things. 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). This said, we could use some other "equivalent" term, such as "side effect", "imperative", "impure", ... Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 10 11:22:41 2012 Received: (at 12314) by debbugs.gnu.org; 10 Sep 2012 15:22:41 +0000 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 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 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 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 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 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Sep 2012 08:21:58 -0700 From: "Drew Adams" To: "'Stefan Monnier'" , "'Eli Zaretskii'" 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> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -7.3 (-------) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.3 (-------) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 10 12:25:18 2012 Received: (at 12314) by debbugs.gnu.org; 10 Sep 2012 16:25:18 +0000 Received: from localhost ([127.0.0.1]:52555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB6nV-00046E-GV for submit@debbugs.gnu.org; Mon, 10 Sep 2012 12:25:17 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:43912) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TB6nT-000465-1i for 12314@debbugs.gnu.org; Mon, 10 Sep 2012 12:25:16 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MA500G006SR9X00@a-mtaout20.012.net.il> for 12314@debbugs.gnu.org; Mon, 10 Sep 2012 19:24:38 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MA500FO06X1O4A0@a-mtaout20.012.net.il>; Mon, 10 Sep 2012 19:24:38 +0300 (IDT) Date: Mon, 10 Sep 2012 19:24:44 +0300 From: Eli Zaretskii Subject: Re: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83k3w1lub7.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> <83627nnc2l.fsf@gnu.org> <83392rm840.fsf@gnu.org> <83pq5ulchr.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12314 Cc: 12314@debbugs.gnu.org, cyd@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12314@debbugs.gnu.org, cyd@gnu.org > Date: Mon, 10 Sep 2012 08:59:26 -0400 > > > See my other message: I think we are talking about 2 different > > things. 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). Alas, the manual itself gives no basis for such an interpretation. It says (in two different places): You can modify the CAR and CDR contents of a cons cell with the primitives `setcar' and `setcdr'. We call these "destructive" operations because they change existing list structure. Here are some functions that rearrange lists "destructively" by modifying the CDRs of their component cons cells. We call these functions "destructive" because they chew up the original lists passed to them as arguments, relinking their cons cells to form a new list that is the returned value. The only danger I glean from these is the "danger" of assigning any meaning to the original list. From unknown Sat Jun 14 03:53:57 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 09 Oct 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator