RE: Add-to-list or setq append...

[Drew Adams]

> 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.