Re: Successor SRFI to SRFI 113
Jeremy Steward 03 Nov 2026 01:01 UTC
Hello Peter,
On 11/2/26 05:43, Peter McGoron wrote:
> Hello,
>
> I am considering creating a revised, (mostly) backwards-compatible SRFI
> 113 that will align SRFI 113 with SRFI 146 (mappings).
As the maintainer for SRFI 113 for CHICKEN, I would find this wonderful.
I've come to really appreciate SRFI 146, and the comparator interface of
SRFI 113 slots in a little nicer if the backend is focused on SRFI
146-like mappings/hashmaps.
(For reference: you might know me as DeeEff on IRC)
>
> The new features would be:
>
> 1. Make set-map and set-unfold have the same argument order as
> hash-table-map and hash-table-unfold (PFN 2).
> 2. Add `set-ref` and `set-ref/default` with an API similar to SRFI 146.
> `set-member` is deprecated.
> 3. Add `set-pop` with an API similar to SRFI 146.
>
> (These are all repeated for the bag API.)
I'll look forward to this being announced separately, but I would also
appreciate separating sets and bags the way srfi 146 does with mappings
and hashmaps, a la:
(import (srfi 113)) ;=> Set API
(import (srfi 113 bags)) ;=> Bag API
Or whatever you find preferable there. I rarely use bags compared to how
often I use sets, so the separation would be helpful for keeping my
imports clean. :)
As for additional requests: It would be nice to have some way to go from
an SRFI 146 hashmap into a set of keys directly.
>
> ___________________________________________
>
> There is one wrinkle. SRFI 113 allows an implementation to require
> *either* a hash function *or* an ordering function. I believe that a
> successor SRFI should make these sets “hash sets,” and leave ordering to
> SRFI 153 (ordered sets) or a successor of it if needed.
Agreed here as well. I often use BTreeSet and HashSet in Rust and like
the option to have either/or collection, but focusing on one of these to
begin with seems prudent to rein in scope.
NOTE: Sometimes the ordering of a set is a very useful behaviour because
operations like `set-first` or `set-last` make no sense whatsoever for
hash sets, but make certain algorithms easy to express.
I don't have tons of time to commit to SRFI development but I will be
trying to watch this in case you're looking for some further feedback.
Regards,
--
Jeremy Steward