Email list hosting service & mailing list manager

Re: [RFC] alist-let: let-like alist destructuring syntax Marc Nieper-Wißkirchen (03 Jun 2022 15:08 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax Marc Nieper-Wißkirchen (03 Jun 2022 15:33 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax Wolfgang Corcoran-Mathe (03 Jun 2022 18:53 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax siiky (04 Jun 2022 11:36 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax Marc Nieper-Wißkirchen (03 Jun 2022 19:08 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax Marc Nieper-Wißkirchen (30 Jun 2022 16:40 UTC)

Re: [RFC] alist-let: let-like alist destructuring syntax siiky 04 Jun 2022 11:36 UTC

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