From: Drew Adams <drew.adams@oracle.com>
To: Eric Abrahamsen <eric@ericabrahamsen.net>, 34708@debbugs.gnu.org
Subject: bug#34708: alist-get has unclear documentation
Date: Tue, 5 Mar 2019 16:16:19 -0800 (PST) [thread overview]
Message-ID: <60367f47-c0b0-45b4-8ccf-169044400a75@default> (raw)
In-Reply-To: <87h8chey12.fsf@ericabrahamsen.net>
Getting from an alist the value for a given key is
straightforward, obvious. So presumably, wrt getting,
`alist-get' doesn't have to say more than that's what
it does.
But _setting_ a value for a given key in an alist is
NOT straightforward. (An alist is not a hash table.)
Often (typically) it means just consing a new alist
entry on the front of the alist. (That's pretty much
the main reason to use an alist.)
But you could alternatively first remove one or more
existing entry for that key from the alist and then
add the requested key+value entry. And if you remove
_all_ such entries first then you don't necessarily
need to add the new entry to the beginning (though
you almost always would, other things being equal).
The ambiguity wrt setting means that the part of
the `alist-get' doc that talks about using it with
`setf', to set the value of the key, needs to be
very clear and correct wrt the implementation. If
the implementation just tacks on a new entry at the
list beginning, then say so. If it does something
else then say what that is.
It's not admissible to just say that it sets the
key to the given value. Why? Because of how alists
are used. Code can very easily make use of an alist
if it knows how it is being maintained. `alist-get'
is a general function, and its doc needs to say
something about how `setf' sets the value (what the
result is).
Similarly wrt removing an alist entry for a given
key. Does it actually remove all such entries, or
does it just tack on a new entry with value nil at
the beginning of the list?
These things need to be specified in the doc.
Alists can be handled in more than one way when
setting and deleting keys. The doc needs to tell
us what `setf' with `alist-get' does to realize
these things.
A user doesn't necessarily care about the "how"
details, but s?he deserves to know the "what":
What is the result of setting the value of a key
or removing a key?
next prev parent reply other threads:[~2019-03-06 0:16 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 [this message]
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
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=60367f47-c0b0-45b4-8ccf-169044400a75@default \
--to=drew.adams@oracle.com \
--cc=34708@debbugs.gnu.org \
--cc=eric@ericabrahamsen.net \
/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).