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:48:11 -0700 (PDT)	[thread overview]
Message-ID: <84e7fa6d-7e89-4c7e-b94d-be40900a3422@default> (raw)
In-Reply-To: <87va0oyt0l.fsf@web.de>

> > > Yes, in these cases eql is not useful.
> >
> > But they are the more common cases, I expect.
> > The cdr of a list is typically a list, not an
> > atom.
> >
> > If this is the case then it's an argument for
> > the default being set to `equal', not `eql'.
> 
> An argument against changing the default is that `equal' is slower.

I don't think such an argument would be a strong
reason.

And it's not even true for atoms.  It is true for
lists.  But in that case `equal' is much more
useful, I think (and I think you agreed, above),
and is less surprising (a potential gotcha).

> > My question in that case is why REMOVE is made
> > to work this way?  Normally, alist element
> > lookup/identification is by key only (or value
> > only).  To look up both key and value it's
> > `member', not `assoc' (or `rassoc').
> 
> As I said: otherwise it would not make sense with `setf'.

I missed where you said that, I guess.  But what
is your reason?  Why doesn't it make sense for
an alist to identify an element by just its key?
Why expect both key and value for only this case
(removal)?  I missed your reason for that.  (But
I see you go into this a bit below, so see below.)

> I think you have a wrong expectation of what the implementation of
> alist-get as a place expression is trying to achieve: It doesn't want to
> implement each and every way of modification operations for alists.  It
> simply implements the most straightforward way of what setting such a
> place could mean.  First of all the expected semantics of setf should
> hold.

How does "the expected semantics of setf"
conflict with what I'm saying?  How does it
require the implementation (design really) of
`alist-get' that you support?  Maybe you're
right, but I don't see an argument supporting
that.

> > That's an operation on general list elements; it's not so much an
> > alist operation.  Why is removing an association different in this
> > regard from adding or changing an association?  Why does it need both
> > key and value?
> 
> As I said: because setf requires you to specify a value, and it only
> makes sense to remove an association if this value is the DEFAULT.  Else
> the value in (setf (alist-get ...) val) would be ignored.  That would be
> nonsense.

This is why I said that removal is not setting
an `alist-get' place.  Setting the value to
DEFAULT would be setting the place.  But removing
the entry is not.

Why have REMOVE instead of just letting users
set the value (explicitly) to DEFAULT?  That
would really follow "the expected semantics of
setf", with nothing funny going on, no confusion.

`alist-get' is a function, not just a gv place.
Argument REMOVE makes no sense for the function
(does it?).  All the other args do make sense
for the function.  Shouldn't all of the args to
a function make sense for it?  Should we add
args that are only used by `setf'?  Has that
been done before?

Adding REMOVE seems like a mistake, to me.  I
suppose I'm kind of acting as devil's advocate
here, but I really do think, so far, that this
is something odd and confusing.  I'm looking
for a good reason.  If I hear it then it will
likely all make sense to me.

> > > You only seem to think of one case: I have a variable x which holds an
> > > alist which I want to manipulate.  There are more cases: the alist
> > > place could be a real nontrivial place.
> >
> > How is that a different case?  But maybe I
> > don't have understand what you have in mind
> > by a real nontrivial place.  Presumably
> > you're talking about an alist with complex
> > elements?
> 
> No, I was talking about complex (nested) place expressions referring to
> an alist.

I still don't follow; sorry.  I guess you mean
an alist embedded in some other list structure?
Could you give an example, showing the advantage
of having REMOVE?

If you think I'm not helping then I'll keep quiet.
I'm hoping that by trying to understand the
rationale I'm helping a bit.





  reply	other threads:[~2019-03-12 16:48 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 [this message]
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=84e7fa6d-7e89-4c7e-b94d-be40900a3422@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).