John,

thanks for having come up with this SRFI. It seems to want to provide two things:

1) A way to create sets using comparators that only provide an order predicate (because code using SRFI 113 in a portable fashion will have to provide both an order predicate and a hash function because the underlying implementation is opaque).

2) Explicit immutability of sets.

Is this right?

I have the fear that we will get an exploding number of APIs with SRFI 153 and the other SRFIs in place when we want to achieve orthogonality:

If we have explicitly immutable ordered sets, there is no reason not to include explicitly immutable mappings with ordered keys, yielding a new SRFI (combining SRFI 146 and SRFI 153). Furthermore, there are legitimate use cases for immutable mappings based on (persistent, functional) hash tables. So we would create just another SRFI for explicitly immutable mappings with hashed keys. And then for immutable sets with hashed elements...

So my question is: Why don't you make SRFI 153 spec-wise a thin layer over SRFI 113 so that importing (srfi 153) guarantees the presence of an implementation of the interface SRFI 113 extended by a few procedures that only make sense for ordered sets that can deal with elements that are ordered but not hashed.

We already have immutability for sets, bags, and mappings by simply using the purely functional interface provided by SRFI 113 and SRFI 146.

Marc