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

I don’t see any issue with the name make-wrapper-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