bug#34708: alist-get has unclear documentation

[Drew Adams <drew.adams@oracle.com>]

> > > 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.