Am Mi., 16. Nov. 2022 um 19:39 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >>> PPS The longer I think about it, the more I believe that
> >>> make-product-comparator is not a good name because there is not really
> >>> a product (but some other kind of (categorical) limit).
> >> The names are chosen because make-sum-comparator makes a comparator for a sum type, and make-product-comparator a comparator for a product type. They aren’t properties of the comparisons per se.
> > Make-product-comparator does not create a comparator for a product
> > type; it creates a comparator for an intersection.  Morally, each
> > comparator argument to make-product-comparator is already a comparator
> > on a product, but not necessarily antisymmetric ("Hausdorff").  Only
> > together with the wrapper-comparators, one gets a product.
> >
> > Example: (make-product-comparator real-comparator real-comparator)
> > does not model the type of the cartesian product of the reals with
> > themselves.
> >
> >> We could go with make-sum-type-comparator and make-product-type-comparator, but those would definitely be too long. I’m reluctant to change the names at the last call, and I especially don’t want to change make-sum-comparator because the name matches the one already used by Schemepunk.
> > This does not necessarily mean that the name already used was chosen well. :)
> >
> > But I think that make-sum-comparator (or make-union-comparator) is not
> > a bad name.
>
> Union is easier to understand than sum. But for non-mathematicians,
> these names are unfortunately overloaded. In math class we learn that a
> union is the set of all the stuff in the other sets. But in programming,
> the point of a union type is you can pick one choice, not all of them.
> The terminology suggests the opposite of the job that the working
> programmer wants done.

Can you explain me? What is the difference between what you learned in
your math class and what you called a union in programming?