Am Fr., 9. Dez. 2022 um 18:09 Uhr schrieb Jakob Wuhrer <xxxxxx@gmail.com>:
>
> Re: Naming of comparator operations
>
> I personally don't really have much of a preference for a particular
> naming scheme (I find the "product" and "sum" terminology perfectly
> adequate).

Can you elaborate on why you find the terminology perfectly adequate?
If they were perfectly adequate, we wouldn't have this decision.

  Nonetheless, I found myself thinking about possible
> terminology.
>
> I've added a small table containing some terms that others have proposed
> and that I thought of:
>
> | product       | sum         | wrapper          | one       | zero   |
> |---------------+-------------+------------------+-----------+--------|
> | product       | sum         | wrapper          | one       | zero   |
> | interweave    | concatenate | lift             | ?         | null   |
> | intersection  | union       | (pre)compose/map | universal | empty  |
> | lexicographic | linear      | indirect         | coarsest  | finest |
> | for-all       | any         | (pre)compose/map | ?         | ?      |
>

The problem with "lexicographic", for example, is that it only makes
sense when the comparators actually define an ordering.  If we were
only talking about orderings, this would indeed be "perfect"
terminology.  However, in general, we are just talking about
equivalence relations on sets (defined by the type predicate).  This
is not the fault of SRFI 228 but the fault of SRFI 128's confusion of
three different things.

> I'll elaborate on a few of them:
>
> I don't think "linear" is a good term for the sum comparator, since it
> may cause confusion with linear (total) orders as opposed to partial
> orders.
>
> If one thinks of comparators as paths or sequences, the "wrapper" more
> or less "lifts" one of those paths to a different topological
> (sub)space, and the sum more or less concatenates two paths.
>
> If one instead thinks of the comparator operation as intersections and
> unions, it makes more sense to me to think of "wrapping" as
> (pre)composition or mapping of elements.
>
> It may be better to mix and match between rows of the table (e.g.,
> lexicographic/concatenated/lifted), but I presented them in this format
> for the sake of brevity.
>
> Kind regards,
> Jakob Wuhrer
>
> Marc Nieper-Wißkirchen <xxxxxx@gmail.com> writes:
>
> > 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
> >>
>