On Fri, Dec 9, 2022 at 3:17 PM Marc Nieper-Wißkirchen <marc.nie...@gmail.com> wrote:
> My point of view here is from the consumers of comparators. In > virtually all cases (e.g. for container types), either an ordering > predicate or a hash function is needed, and which one of them is > needed is determined by the use case (e.g. data structure). Of course. What I didn't foresee is that hash-based and order-based libraries would end up with distinct APIs. If you look at the first library to use comparators, SRFI 113, you'll see that it's deliberately ambiguous about whether the implementation is tree-based or hash table based, hence you should always pass a comparator providing both. That didn't turn out to be the way that things went in most later SRFIs, so they could readily use more limited comparators. One specific problem with it is that there are many procedures that just don't work well on hash-based data structures, like the largest and smallest element/key operations. One of my unfulfilled ambitions is to change SRFI 113 (with or without renumbering) to be specifically the hash-set/hash-bag library, which is what its sample implementation is, and revive SRFI 153 as the ordered set (and maybe bag) library. If I did that, there would no longer be any ambiguous libraries. But I am still unsure that pragmatically comparators should be split into two, as it doubles the size of SRFI 128. I have a similar plan to have a single typeclass object for monads, idioms (applicative functors), and functors, such that there is only one set of generic operations over them, though of course each context object has its own methods. There is a sketch at < https://github.com/johnwcowan/r7rs-work/blob/master/ContextsCowan.md>; I'd be interested to know what you think of this, not the details but the general idea. (This does not exclude the idea of *syntactic* contexts, but that is almost, but not quite, wholly different.) My argument was that it would be > clearer if we had, say, OrderedComparators and HashComparators and if > we had specialized procedures for each type (e.g. SRFI 228 would have > had a make-lexicographic-comparator constructor for the ordered > subclass. > It's a tradeoff.
