On 8 Dec 2022, at 10:00, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

>> Marc also wrote: ‘the spec should really add the (make-product-comparator real-comparator real-comparator) example.’ I seem to have missed this. This should behave identically to the real-comparator itself – that seems intuitively correct to me. I assume the issue is that it isn’t actually a comparator over a product type in the formal sense. I don’t feel the need to consider perverse cases in the naming of the procedures.
>
> My point was that when the procedure was called
> make-product-comparator, the spec should include a warning that the
> procedure would not return a comparator of the product type.

Since the latest draft, there is already a warning about this:
‘Note: Despite the name, this procedure actually creates comparators which are more general than a comparator over a product type, because each of the given comparators has its own type test.’
although your example shows that the last clause is also not always relevant.

I don’t think it needs an example in the spec test, though the warning needs revising anyway, so I’ll think about adding one.

>> I don’t see any issue with the name make-wrapper-comparator.
>
> My point here was that you might want to find a more specific name
> that is comparable to make-intersection/union-comparator.

Well, I think the ideal as you said is to find non-mathematical replacements for the terms product and sum here, so that nobody can complain about the names being mathematically incorrect. But if we stick with mathematical names, maybe it would be better to keep the theme for all three.

Daphne