Re: finalizing Daphne Preston-Kendal (08 Dec 2022 08:50 UTC)
Re: finalizing Marc Nieper-Wißkirchen (08 Dec 2022 09:01 UTC)
Re: finalizing Daphne Preston-Kendal (08 Dec 2022 09:05 UTC)
Re: finalizing Jakob Wuhrer (09 Dec 2022 17:09 UTC)
Re: finalizing Marc Nieper-Wißkirchen (09 Dec 2022 17:21 UTC)
Re: finalizing pinoaffe (09 Dec 2022 18:40 UTC)
Re: finalizing Marc Nieper-Wißkirchen (09 Dec 2022 18:56 UTC)
Re: finalizing John Cowan (09 Dec 2022 20:04 UTC)
Re: finalizing Marc Nieper-Wißkirchen (09 Dec 2022 20:17 UTC)
Re: finalizing John Cowan (18 Dec 2022 20:46 UTC)
Re: finalizing Marc Nieper-Wißkirchen (19 Dec 2022 16:38 UTC)
Re: finalizing Daphne Preston-Kendal (09 Dec 2022 17:30 UTC)

Re: finalizing pinoaffe 09 Dec 2022 18:12 UTC


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.

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.

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.

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