Am So., 18. Dez. 2022 um 21:46 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Fri, Dec 9, 2022 at 3:17 PM Marc Nieper-Wißkirchen <xxxxxx@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.

Another problem I see is that the possible advantage of being able to
work with either type of comparator is mitigated by the undecidability
of which type is more efficient both on the provider and consumer
side.

> 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.

At the same time, it simplifies 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.)

This case is a bit simpler than the comparators because each monad is
an idiom and each idiom is a functor.  So one can use single
inheritance to model the context types in a satisfactory way.  One has
functor?, idiom? and monad? with the obvious implication.  I would
replace make-context by three different procedures, make-functor,
make-idiom, make-monad.

The general idea looks good to me.

>> 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.

We should at least evaluate if it makes sense to retroactively split
comparators into two or three classes for the purpose of R7RS-large.