Perhaps, though given that it is already used slightly differently in a very well-known language can also cause hiccups.
For the record, algebraic data types get there names from the fact that the “number” of instances that are under a given type gets added or multiplied together. Let’s say we have a ColorChannel “enum” of R, G, B. That is there are 3 instances ever under this ColorChannel type. Let’s create (with some syntactic sugar) an 8bit unsigned int which has exactly 256 possible instances.
Now create a Pair (ColorChannel, u8) type. This will be a product type, since the number of possible constituents is 3x256.
Let’s look at the often used Option type, which wraps another type. This looks something like
enum Option<T> {
Some(T),
None
}
We have two possible types here, but one can contain T possible types. So Some(T) is basically a product type of 1 other type, resulting in it holding that type’s cardinality, while None has a single instance — the Optional sum type thus has card(T)+1 possible instances.
For the record, algebraic data types get there names from the fact that the “number” of instances that are under a given type gets added or multiplied together. Let’s say we have a ColorChannel “enum” of R, G, B. That is there are 3 instances ever under this ColorChannel type. Let’s create (with some syntactic sugar) an 8bit unsigned int which has exactly 256 possible instances.
Now create a Pair (ColorChannel, u8) type. This will be a product type, since the number of possible constituents is 3x256.
Let’s look at the often used Option type, which wraps another type. This looks something like enum Option<T> { Some(T), None }
We have two possible types here, but one can contain T possible types. So Some(T) is basically a product type of 1 other type, resulting in it holding that type’s cardinality, while None has a single instance — the Optional sum type thus has card(T)+1 possible instances.