On 6/3/22 20:04, John Cowan wrote:
> I have decided to remove alist support from SRFI 225 in its current form,
> because manipulating an alist generically creates curious results.  If you
> add an association with an existing key it is prepended, which is fine.
> But if you then delete that association, the previous association appears,
> which is not what people expect from a delete.

That's funky, but people can decide for themselves. I would argue that
using an `alist-delete/all` instead of dropping support for alists would
be a better choice, if explicitly stated that the generic delete is
inefficient for alists and better performance can be got using
alist-specific procedures, *if you know keys aren't duplicated*.

siiky