From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: Add-to-list or setq append... Date: Wed, 4 Aug 2010 08:42:04 -0700 Message-ID: <1E82BF30DF304CB79DA7311A008FF428@us.oracle.com> References: <1CEA23A32F7043F282E60BDDC2485EB0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1280937452 3569 80.91.229.12 (4 Aug 2010 15:57:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Aug 2010 15:57:32 +0000 (UTC) To: "'Andrea Crotti'" , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Aug 04 17:57:31 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OggLJ-00041P-Qw for geh-help-gnu-emacs@m.gmane.org; Wed, 04 Aug 2010 17:57:22 +0200 Original-Received: from localhost ([127.0.0.1]:53532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ogg98-0006cC-19 for geh-help-gnu-emacs@m.gmane.org; Wed, 04 Aug 2010 11:44:46 -0400 Original-Received: from [140.186.70.92] (port=46803 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ogg8I-0006Xf-Fs for help-gnu-emacs@gnu.org; Wed, 04 Aug 2010 11:43:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ogg8H-0003QP-1P for help-gnu-emacs@gnu.org; Wed, 04 Aug 2010 11:43:54 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:33384) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ogg8G-0003QL-QU for help-gnu-emacs@gnu.org; Wed, 04 Aug 2010 11:43:52 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o74FhnGM028871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Aug 2010 15:43:51 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o742Ii2w028520; Wed, 4 Aug 2010 15:43:49 GMT Original-Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 484638861280936525; Wed, 04 Aug 2010 08:42:05 -0700 Original-Received: from dradamslap1 (/10.159.217.40) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Aug 2010 08:42:05 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acszq5+V5tFlSQewRgaDd8+I83c5xQANVbsg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C598AB5.01B1:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:74437 Archived-At: > ELISP> my-l > ((1 . 3) > (1 . 2)) > > ELISP> (add-to-list 'my-l '(2 . 3)) > ((2 . 3) > (1 . 3) > (1 . 2)) > > it actually not add it ONLY if they're really equal, which is > desirable in my opinion. `add-to-list' adds an element ONLY if it is NOT `equal' to any existing element. `add-to-list' is for any list, not just an alist. `equal is used to test whether an _entry_ is already present in the list. `equal' is applied to the potentially new entry and to each list entry (aka item, element). This is not a comparison of the cars or cdrs of the entry; it is a comparison of the entry as a whole: both its car and cdr. The cons (2 . 3) is not `equal' to any item in the list, so it is added. > What's the point in having twice the same cons in auto-mode-alist? None. I misspoke in mentioning shadowing wrt the examples in your second mail. I was thinking of something like this, where only the alist keys are compared: (add-to-list 'auto-mode-alist '("\\.ml\\w?" . tuareg-mode) nil (lambda (x y) (equal (car x) (car y)))) That would allow for only one entry with the given key. I was speaking to why you might want to allow more than one such - which I think got closer to your original question. Your original question was not just about `auto-mode-alist'. You asked why someone might use (setq list (append (list element))) instead of (add-to-list list-va element). Any list can be used for anything you like. Multiple occurrences of `equal' items or even `eq' items can often be useful. It is often the case in using alists, in particular, that you do not care whether there are also other items with the same key, because only the first one is seen (using the usual alist operations). If you don't care about removing duplicates (wrt the key) then, well, you don't care about removing them. And in some cases, as I said, you want to preserve the older alist entries so that you can retrieve them or make them active at some point. You might want to use the alist as a stack of definitions or in some other way where old items can be useful. One program, in one context, adds an entry to `auto-mode-alist'. In a different context, another adds an entry that shadows the first one (it has the same key). Upon leaving the second context you might well want to make the previous association active again. Removing the shadowing entry is one way to do that. If the original entry was deleted then you cannot retrieve it (but you could add it again). > Then the real difference is that I add in the end instead of at the > beginning, That is not the real difference. That is not even a difference - you can add at either the end or the beginning with either `add-to-list' or `setq'. The real differences are those I outlined previously. When I said that `add-to-list' does not assure that the entry is at the start of the list I was referring to the case where the entry is already present somewhere down the list, so it is not added. In that case, it is not at the head of the list. You might or might not care that the item is first in the list. It all depends how you use the list. > and in that case I don't shadow an already present value... You never shadow an `equal' entry with a new one if you use `add-to-list' - there are no occurences of `equal' items. If you in some other way add an `equal' item at the end or otherwise after some `equal' occurrence in the list, it is itself shadowed. You can do anything you want with a list. You can put an item at any position, including an item that is `equal' to some other item. You can put it in any position relative to any number of such `equal' items, thus determining its "shadowing depth" (for lack of a better term), which determines at what point it would be unshadowed if you pop items of the list head. Both of the cliches you showed are useful (`add-to-list', `setq'). They are different.