Am Fr., 9. Dez. 2022 um 21:04 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> one for setoids, one for totally ordered setoids, and one for setoids
>> with a hash function (with forgetful functors from the latter two to
>> the first).
>
>
> I think this is the wrong analysis.  If there is no equality predicate, then there is no meaningful comparator at all: it makes no sense to ask "Does electron A come before electron B?" given that electrons lack identity.  So we have two properties and therefore four cases: neither orderable nor hashable, orderable   but not hashable, hashable but not orderable, and both hashable and orderable.

All my proposed "type classes" have an equality predicate, so we are
in agreement, at least with the first three cases.

> The reason for setting up the Comparator typeclass as I did is that most Scheme objects are both orderable and hashable (with the usual exceptions of procedures, ports, etc), although the order is not necessarily a semantically meaningful order.  In many cases, such as B-trees, it doesn't matter what the order is as long as there is one.  The same is true of hash functions mutatis mutandis.  So all the cases except "orderable and hashable" are more or less degenerate.  So ather than burdening users with the necessity of specifying an ordering predicate and/or a hash function that aren't going to be useful in their particular use cases, I allow them to specify simply #f and then throw an error if that is inadequate.
>
> I hope this is helpful.

Thanks for explaining your rationale.

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).  In
particular, for the actual use cases, all procedures that create
comparators from, say, other comparators (e.g. as in SRFI 228) always
have to consider both the possibility of an ordering predicate and the
possibility of a hash function.  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.

The SRFI 228 comparators correspond to some (informal) type(class) of
the form (Eq | Ord | Hash | Ord x Hash).  A Haskeller (SRFI 228 makes
a comparison to Haskell) would have created three distinct type
classes (and rightfully so IMO).