The response below should not concern the finalization of SRFI 228 and
is only loosely related.

Am Fr., 9. Dez. 2022 um 19:40 Uhr schrieb pinoaffe <xxxxxx@gmail.com>:

> Marc Nieper-Wißkirchen <xxxxxx@gmail.com> writes:
> > Am Fr., 9. Dez. 2022 um 18:09 Uhr schrieb Jakob Wuhrer <xxxxxx@gmail.com>:
> >> 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.
>
> I'm not saying they're perfect, just adequate.  I think the phrase
> "perfectly adequate" may have been somewhat misleading.

Thank you for explaining.

> I consider these terms adequate because if I squint at the operations in
> the right way, they behave just like products and sums (in the algebraic
> sense).  Furthermore, I don't see much danger of the terms being
> misinterpreted.

If you squint long enough, every binary operation looks like a product. :)

> The terms "product", "sum", "wrapper" don't capture all of the
> particularities of the operations, but I don't think any naming scheme
> could do that.  Furthermore, I think that any naming scheme will require
> at least some level of "squinting" to interpret, so I don't think
> there's much room for improvement.
>
> > 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).
>
> The fact that we're dealing with an order and/or a hashing function on
> the quotient of a (sub)set by an equivalence on said subset is precisely
> why I don't think it's much of an issue that certain terms don't
> describe all particularities/usecases that well: I don't think it's
> possible to significantly improve the terminology, so I don't mind the
> imperfections.

I agree that the perfect terminology hasn't been found.

> > This is not the fault of SRFI 228 but the fault of SRFI 128's
> > confusion of three different things.
>
> I agree that the source for the need to compromise on the terminology
> lies not within SRFI 228, but in earlier decisions.
>
> I would pesrsonally not consider those decisions to be "confused",
> though adapting an abstraction that mirrors well-known and
> well-understood structures from either algebra or category theory may be
> more useful if done well (and this is a big if).

By confusion, I meant that SRFI 228 specifies something that
figuratively describes an animal, a cat, a dog, or something with the
characteristics of a cat and dog.  Of course, by itself, such a type
is well-defined.  But arguably, for understanding it and for using it,
it would have been preferable if we had three distinct "type classes",
one for setoids, one for totally ordered setoids, and one for setoids
with a hash function (with forgetful functors from the latter two to
the first).