Am Mi., 16. Nov. 2022 um 13:53 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> 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.

Bundling can still be useful, namely bundling the type predicate with
either an order relation or a hash function.

With a bare type predicate, I cannot check errors early.

So I would propose "orders" and, say, "hashed sets" (not hash-set!):

(define-record-type setoid (fields type-predicate equality-relation))
(define-record-type order (parent setoid) (fields type-predicate
order-relation))
(define-record-type hashed-set (parent setoid) (fields hash-function))

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

Make-product-comparator does not create a comparator for a product
type; it creates a comparator for an intersection.  Morally, each
comparator argument to make-product-comparator is already a comparator
on a product, but not necessarily antisymmetric ("Hausdorff").  Only
together with the wrapper-comparators, one gets a product.

Example: (make-product-comparator real-comparator real-comparator)
does not model the type of the cartesian product of the reals with
themselves.

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

This does not necessarily mean that the name already used was chosen well. :)

But I think that make-sum-comparator (or make-union-comparator) is not
a bad name.

The name make-wrapper-comparator stands out because it doesn't use
mathematical language; it is mathematically a kind of quotient, so
make-quotient-comparator could make sense.