From: Robin Tarsiger <rtt@dasyatidae.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: add-to-list vs cl-pushnew
Date: Fri, 4 Dec 2020 15:40:43 -0600 [thread overview]
Message-ID: <8c92ca59-a6bd-4d9a-341a-cf481b5494b1@dasyatidae.com> (raw)
In-Reply-To: <jwvzh2tcobr.fsf-monnier+emacs@gnu.org>
Stefan Monnier wrote:
>> (Aside: why not replace add-to-list with cl-pushnew always?
>
> Good question.
>
>
> Stefan "who really doesn't like `add-to-list`"
In case it was interpreted differently, my original question was
rhetorical. There's several reasons I can think of to keep using
add-to-list's current behavior as-is for its primary use case,
as opposed to recommending that new code avoid it entirely:
- The unquoted variable name argument leaving available the
make-local-variable idiom and similar.
- The presence of the APPEND arg. This being a toggle lets it
be plumbed through wrapper functions easily, so that you can
write (defun foo-add-bar (bar &optional at-end) ...) and call
(add-to-list 'foo-bar-list rectified-bar at-end) from it.
- The use of equal, not eql, as the default comparison function.
This becomes important if any of the list variables contain
almost anything other than symbols, and I could see eql as a
default in this case leading to subtle bugs since duplicates
wouldn't be common, nor necessarily punished in practice.
(eql "foo" "foo") is allowed to be nil.
- The docstring mentioning the potential need for eval-after-load
to handle package ordering issues, which is an easy source of
bugs in add-to-list's main use case but irrelevant in most
list processing. If you just use the general list processing
functions, there isn't as good a place to warn about that.
- I recall a while ago that pulling in the cl library for one
or two symbols was considered bad style because it was quite
heavy, but I don't know if that's still true.
However, I would not be averse to finding it a better primary name
and demoting the add-to-list name to being a compatibility alias,
especially if new elisp programmers are likely to stumble into it
and skip over the the "please do not abuse for general list
manipulation" part of the doc, since the name itself both doesn't
imply that right now and is paradoxically easier to find than the
push family by some (albeit not-so-good) routes. If you do this,
you'd want to hit add-to-ordered-list too.
I also think upon looking at the "List Variables" section again
that it could usefully be split up, since putting push and
add-to-list right next to each other when the latter is so much
more specialized could be structurally misleading. (The "please
do not abuse" text is also nowhere there, instead obscured behind
"Do not use this function when SYMBOL refers to a lexical
variable.", which could lead off into the weeds of e.g. "ah,
so if I want to use this function on locals then I have to not
use lexical-binding" to someone not already receiving usage
cues from other places.)
-RTT
next prev parent reply other threads:[~2020-12-04 21:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 2:17 Lispref add-to-list - doc is unnecessary convoluted Arthur Miller
2020-12-04 2:27 ` Christopher Dimech
2020-12-04 2:36 ` Robin Tarsiger
2020-12-04 3:29 ` Arthur Miller
2020-12-04 3:35 ` Arthur Miller
2020-12-04 8:35 ` Lars Ingebrigtsen
2020-12-04 8:29 ` Eli Zaretskii
2020-12-04 15:28 ` Arthur Miller
2020-12-04 15:56 ` Robin Tarsiger
2020-12-04 16:14 ` Ad-hoc list structure tutorializing (was: Lispref add-to-list - doc is unnecessary convoluted) Robin Tarsiger
2020-12-04 20:24 ` Ad-hoc list structure tutorializing Stefan Monnier
2020-12-04 21:12 ` Christopher Dimech
2020-12-05 7:45 ` Eli Zaretskii
2020-12-06 5:45 ` Richard Stallman
2020-12-06 5:57 ` Robin Tarsiger
2020-12-06 14:01 ` Arthur Miller
2020-12-06 5:39 ` Richard Stallman
2020-12-04 21:40 ` Robin Tarsiger [this message]
2020-12-04 21:51 ` add-to-list vs cl-pushnew Robin Tarsiger
2020-12-04 22:47 ` Sv: Ad-hoc list structure tutorializing (was: Lispref add-to-list - doc is unnecessary convoluted) arthur miller
2020-12-04 17:03 ` Lispref add-to-list - doc is unnecessary convoluted Drew Adams
2020-12-04 17:24 ` arthur miller
2020-12-04 18:02 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8c92ca59-a6bd-4d9a-341a-cf481b5494b1@dasyatidae.com \
--to=rtt@dasyatidae.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.