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 20:40 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 20:40 UTC

> And what should generic deletion do: delete the first or delete them
> all?

The generic delete should delete all the keys (for alists), so the
behaviour is uniform. That's what I meant on my email with "using
alist-delete/all".

> It doesn't make sense to have both generic functions, given that
> alists are probably the only case in which the distinction is needed.

Yeah, would be silly.

>
> So since this SRFI is already very late, and since it's possible to create
> your own DTOs or to write a new SRFI, it's better to leave them out rather
> than to provide them wrongly.

Ah in that case...