unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, 34708@debbugs.gnu.org
Subject: bug#34708: alist-get has unclear documentation
Date: Tue, 12 Mar 2019 09:18:27 -0700 (PDT)	[thread overview]
Message-ID: <5fac8365-68d2-4cc5-b5c3-d2658350ea28@default> (raw)
In-Reply-To: <871s3c14s9.fsf@web.de>

> > OK.  Put it differently: it's worth documenting that updating an alist
> > entry with `setf' is a "destructive" operation: it can change list
> > structure.  Dunno whether that is already said somewhere, but even if
> > it is, a reminder wouldn't hurt.
> 
> But isn't that trivial?  How else could we add associations?

Yes, it's true of `setf' in general.  It's still
worth repeating, I think (just one opinion).
One person's "trivial" is another's "gotcha".

But apparently we don't even point this out in
the Elisp manual doc for `setf', alas.

And even for `setcdr' etc., the manual doesn't
repeat it.  It mentions it only in the parent
node, `Modifying Existing List Structure'.

`setf' is not mentioned in that node, BTW.
Perhaps some mention would make sense, saying
that when the place to be modified is a list
the list structure can be modified - it is a
so-called "destructive" operation.

"Destructive" is mentioned in node `Rearrangement',
however.  Why it's not mentioned in nodes `Setcar'
and `Setcdr' I don't know.  (Sure, those nodes do
make clear that list structure can be modified.
But they don't specifically call them "destructive"
operations.)

I suggest we document explicitly for `alist-get'
that using it as a generalized variable is a
"destructive" operation - in both the doc string
and node `Association Lists'.

Whenever we say of some function that it "is a
generalized variable suitable for use with
`setf'", I think we should add that using it to
modify a list is a "destructive" operation, i.e.,
it can change list structure.

We should be a bit more consistent.  We say
`delq' is a "destructive" operation, but we
don't say that explicitly about `delete' with
a list (node `Sets and Lists').  (We do say it
indirectly.)

I'm not crazy about the term "destructive" for
changes to list structure, BTW.  But that's the
term Emacs Lisp doc has chosen to use.  As such,
we should call it out everywhere it's applicable
- or nowhere.  It is not the case, for example,
that `setcdr' is more "destructive" than `setf'
+ `alist-get'.

Some get so excited about such "destruction"
that they make a big deal about strongly
discouraging users from using such functions.
I don't.  But I do think it's worth explicitly
making users aware of which functions can
change list structure (as well as what that
means - the consequences).





  reply	other threads:[~2019-03-12 16:18 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-02  4:50 bug#34708: alist-get has unclear documentation Miguel V. S. Frasson
2019-03-02  9:25 ` Michael Heerdegen
2019-03-02 15:40   ` Miguel V. S. Frasson
2019-03-02 18:10     ` Michael Heerdegen
2019-03-02 19:06       ` Eric Abrahamsen
2019-03-03  0:15         ` Phil Sainty
2019-03-03 12:50           ` Michael Heerdegen
2019-03-19  1:35             ` Michael Heerdegen
2019-03-02 19:51       ` Miguel V. S. Frasson
2019-03-02 20:32         ` Eric Abrahamsen
2019-03-03 11:32       ` Miguel V. S. Frasson
2019-03-03 12:21         ` Michael Heerdegen
2019-03-03 15:51           ` Drew Adams
2019-03-03 16:49             ` Eric Abrahamsen
2019-03-04 16:24             ` Eric Abrahamsen
2019-03-04 16:38               ` Michael Heerdegen
2019-03-04 17:16                 ` Eric Abrahamsen
2019-03-04 18:22                   ` Michael Heerdegen
2019-03-04 22:49                     ` Eric Abrahamsen
2019-03-05 12:35                       ` Michael Heerdegen
2019-03-05 22:50                         ` Eric Abrahamsen
2019-03-06  0:16                           ` Drew Adams
2019-03-11 13:39                             ` Michael Heerdegen
2019-03-11 14:52                               ` Drew Adams
2019-03-11 16:19                                 ` Michael Heerdegen
2019-03-11 17:48                                   ` Drew Adams
2019-03-12 13:04                                     ` Michael Heerdegen
2019-03-12 14:48                                       ` Drew Adams
2019-03-12 16:08                                         ` Michael Heerdegen
2019-03-12 16:48                                           ` Drew Adams
2019-03-12 17:45                                             ` Michael Heerdegen
2019-03-12 13:12                                 ` Michael Heerdegen
2019-03-12 14:53                                   ` Drew Adams
2019-03-12 15:38                                     ` Michael Heerdegen
2019-03-12 16:18                                       ` Drew Adams [this message]
2019-03-12 17:55                                         ` Michael Heerdegen
2019-03-15 15:54                                           ` Michael Heerdegen
2019-03-15 18:48                                             ` Eric Abrahamsen
2019-03-27 22:31                                               ` Michael Heerdegen
2019-04-19  1:33                                                 ` Michael Heerdegen
2019-04-19  2:24 ` bug#34708: Thanks Miguel V. S. Frasson
2019-04-19  4:18   ` Michael Heerdegen

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5fac8365-68d2-4cc5-b5c3-d2658350ea28@default \
    --to=drew.adams@oracle.com \
    --cc=34708@debbugs.gnu.org \
    --cc=eric@ericabrahamsen.net \
    --cc=michael_heerdegen@web.de \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).