On 16 Nov 2022, at 13:33, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

> By the way, this reveals a problem with the current SRFI
> 128-comparator proposal.  They mix some very different things, namely
> type predicate+order relation on the one hand and type predicate+hash
> function on the other.  Consumers usually only need one of the two
> aspects (which are both optional), but not any. The name
> make-lexicographic-comparator is strange when no order relation is
> defined; on the other hand, make-intersection-comparator (or
> make-product-comparator) is a name that does not specify the total
> order at all.

Perhaps it would be better, from this perspective, to go back to giving each data structure constructor bare procedures for whichever it actually needs. But I think it's a useful convenience to have them bundled up, even if not quite theoretically sound.

> PPS The longer I think about it, the more I believe that
> make-product-comparator is not a good name because there is not really
> a product (but some other kind of (categorical) limit).

The names are chosen because make-sum-comparator makes a comparator for a sum type, and make-product-comparator a comparator for a product type. They aren’t properties of the comparisons per se.

We could go with make-sum-type-comparator and make-product-type-comparator, but those would definitely be too long. I’m reluctant to change the names at the last call, and I especially don’t want to change make-sum-comparator because the name matches the one already used by Schemepunk.

Daphne