all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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



  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.