>     I think convenience procedures like `alist-ref` or `assoc?` should not
>     make the distinction. Then they can return a single value.
>
> If `alist-ref' is to appear in any SRFI*, it should actually take a
> failure argument as it is common with all the other `-ref' procedures.
> (See my other post for the corresponding xlist example.)

Sounds reasonable.

>     SRFI 189
>     `lisp->maybe` can be used to convert that value to a Maybe.
>
> That would hardly be helpful at this stage because we would have already
> lost the distinction between a false entry and a missing association.

Ah, you are right. A `(maybe-assoc key alist)` would be in order. And
`maybe-list-ref`, `maybe-hash-table-ref`, etc.

IMHO, the RnRS `assoc` procedure sets a precedent that xlist and alist
should be regarded as the same data type. It returns the cdr, which in
an xlist's case is the full list of values for the given key.

For most people, hash-tables are a natural collection type since they
can't contain duplicate keys and the single-value case is eaiest to express.

Lisp is kind of funny in that alists came first, and those are more
specialized with support for duplicates and the multiple-value case is
easier to express (the natural `cdr` or a cons is a proper list, and
improper lists are something special).

So an API that "pretends" that an alist is like a "normal" collection
(single value, no duplicate keys) is useful. As is an API that
"pretends" that a "normal" collection like a hash-table is in fact a
multiple-value collections :)

>     In any case, alist convenience procedures are commonly needed enough
>     that they'd be better off not depending on fancier things like
>     Maybe/Either. Alist stuff is useful with R7RS-small, or even with
>     subsets of that language.
>
> It's all about control- vs data-driven workflows.  In the former case,
> we are looking for a failure argument; in the latter case we want to use
> Maybe's or overload #f.

Perhaps both are useful. RnRS specifies `assoc` and exceptions (and
multiple values), so minor variations on that are a natural starting point.

> *Lassi, would you be interested to write such a SRFI together with me?
> (Not in the very near future because there are still some I have to wrap
> up, but also not too far in the future). I think we would complement
> each other quite well. I'm thinking of a SRFI that organizes an
> interface to alists and xlists (help me with a better prefix) in the
> same shape as all the other interfaces for data structures we have in
> R7RS-large (SRFI 125, SRFI 146, ...).

Sure, sounds great, and agreed!

Arne has expressed an interest in standardizing alist stuff previously
as well, so we should also include him if he wants to join in.

A survey of existing alist procedures would be good preparation. I don't
know of any semi-standard library other than the RnRS, SRFI 1, and SLIB
ones which are minimal. We could do a quick check of the major
implementations' manuals.