Am Mi., 16. Nov. 2022 um 19:54 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > Can you explain me? What is the difference between what you learned in
> > your math class and what you called a union in programming?
>
> The obvious connotation of "union", from set theory, is "all of these".
>
> But we use a union type when we want to match "any of these" types.

When you have a union in set theory of two sets A and B, an element of
the union is either an element of A or an element of B. [*]

When you have a (tagged) union in a programming language of two types
A and B, a value of the union is either a value of A or a value of B.
[**]

This is entirely parallel.

[*] When we all non-disjoint sets A and B, it is slightly more
complicated, but we can achieve the same with union types in
programming (take a C union of two structure types whose initial
members are of the same type).

[**] Note that even in C, most unions have to have at least an
implicit tag because you need to know which type of value the union
currently holds (writing a char and reading a pointer is undefined
behavior).

> There's a confusion between "any" and "all". "Any" is more precise. A
> "sum type" and a "product type" both deal with "all of these types", but
> they do it differently.
>
> When we want to have "all of these" values we put them in a collection
> such as a list, or indeed a set. A product type is closer to this meaning.

struct = product type
union = sum type

When you want to model a list, you need to combine them:

A list is the empty list or a pair of an element and a list.  Here
"or" marks the sum, "and" marks the product type.

> There's more of this with "row types", etc. The people who write higher
> order functions (e.g. SRFI 1) tend to use everyday language that is easy
> to understand and does not have overloaded connotations, but somehow the
> types people use these verbose and confusing theory words. It detracts
> from the usability of the tool.

I disagree.  Often, once you have gotten the theory right, you know
exactly how to proceed in programming.  But without getting the
terminology right, getting the theory right would be hard.

If you find any of these words confusing, ask about them and learn
something new.