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