Subject: bug#34708: alist-get has unclear documentation

From: Michael Heerdegen <[email-masked]>
Date: Tue, 12 Mar 2019 17:08:58 +0100

Drew Adams <[email-masked]> writes:

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

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

In one, special, case - when setting the place to the default - setting
the place can be achieved by removing an association from the alist
(because after removing the association DEFAULT is returned by
evaluating the place expression), but it's only done if explicitly
requested by providing an extra argument.  If you don't like using it
like that, just use something else.

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

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

Michael.