Are these really algebraic data types?

Coconut’s documentation for the data keyword states that it lets you create immutable ADTs. I see a nice concise language for creating immutable product types, but for it to truly offer an algebra, I believe[1] it would have to offer sum types.

The data keyword lets us multiply two types. For instance, we can multiply the int type with the string type by making a type T that has two fields, one of them an int and the other a string. In every instance of T both fields are mandatory.

If we could add the types int and string, it would mean we could create a new type T for which every instance could include either a string or an int, without including the other. That is, the type T would offer multiple constructors, which when called create instances of T with different fields.

Right?

---

[1] My understanding* of the term “algebra” is that it implies both addition and multiplication, and that for types, “multiplication” is the conjunction (and) operator, while “addition” is the disjunction (or) operator.

That interpretation seemed very weird to me until I noticed its implications for the size of the sets in question: If type A has 5 members and type B has 6, then their sum has 11 members, while their product has 30.

Sorry if I’m stating things you already know; I’m trying to keep a wide potential readership.

[evhub]

@JeffreyBenjaminBrown I think this needs to be documented better, because my thinking on how best to do this in Coconut has evolved a lot since I wrote most of the documentation, but I’ll show you my current thinking as to how to translate sums and products into Coconut. Consider the Haskell data type

data Something = SomeInt Integer | SomeFloatPair Double Double | Nothing

then, I would translate that into

class Something
data SomeInt(x: int) from Something
data SomeFloatPair(x: float, y: float) from Something
data Nothing() from Something

which basically does the exact same thing. There are a couple of remaining things with that implementation that I am unsatisfied with, however. First, I think the idiomatic syntax here is pretty good but it needs to be documented so people know that this is the idiomatic way to do it. Second, if you want the equivalent of adding deriving (Eq, Ord) to the Haskell code, you have to write something like this derivingEqOrd function (which you can see used here), which is rather messy. At some point, I would like to go through the documentation and clean up all my uses of algebraic data type so that they all actually make sense.

[3noch]

In a dynamic language this is mostly moot because you’re essentially choosing to have all your errors at runtime anyway. The only thing you could is try to throw exceptions sooner rather than later, but always during runtime. The best that could be done here would be some sort of MyPy integration I think. I’m not sure if MyPy supports totality checking of sums.