Am Do., 8. Dez. 2022 um 09:50 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> (I hope Arthur doesn’t mind me posting my reply to his message to me back to the public list.)
>
> On 7 Dec 2022, at 17:59, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> > Hi, Daphne.  What's your feeling about SRFI 228 at the moment?  I see two threads that might be considered unresolved:
> >       • Any further last call comments on SRFI 228?
> >       • Last call for comments on SRFI 228: Composing Comparators
> > #1 is Marc's message about the his unhappiness with the names.  I'm not sure you want to proceed further with that, although I would certainly understand if you wanted to give that a little more time.
>
> Yes, I would like some more time for this. I think make-union-comparator and make-intersection-comparator are potentially a good solution (perhaps with corresponding renaming of the base cases to something like comparator-empty-set and comparator-universal-set).
>
> My problem with the name make-intersection-comparator is that it arguably relates only to the domain i.e. the type test, and not to the actual comparison procedures and how they work.

One also takes the intersection of the equality predicates, so the name is fine.

That it doesn't cover the ordering predicate and the hash function is
okay because the general comparator does not have an ordering or a
hash function.  Ceterum conseo that the comparator "type class" must
be deprecated and replaced by "type classes" with clear domains (Eq,
Ord, Hash).  But that's outside of SRFI 228.

> Make-for-all-comparator might be better, but only because of R6RS's use of for-all as a left-to-right every procedure, and probably not in any more formal sense.

> 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.  The
example with real-comparator would illustrate this.

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

>
> > #2 is the discussion with Shiro.  You've responded to some earlier messages, but I can't tell for certain when the issue is resolved.
>
> As far as I know, the issues raised by Shiro were resolved by the last draft, but I haven’t heard back from him.
>
>
> Daphne
>