Am Mi., 16. Nov. 2022 um 13:53 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>
> On 16 Nov 2022, at 13:33, Marc Nieper-Wißkirchen <marc.nie...@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.
