• Successor SRFI to SRFI 113 Peter McGoron (02 Nov 2026 12:48 UTC)
    • Re: Successor SRFI to SRFI 113 Jeremy Steward (03 Nov 2026 01:02 UTC)

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