Hacker News Reader

Comment by galaxyLogic | Hacker News Reader

What are algebraic data-types good for? From another comment here they enable you to declare things like "this field could contain a string or an integer".

Would it make more sense to make the field be always integer or always string? Then you would have two separate data-types and you could use the one you need when you need to?

You can always convert an integer to string if needed, and vice versa.

I can understand it gives you more flexibility that you can specify something MAY be either X or Y. But that makes the data-type specification more complicated. If you can do with X only why not just stick to it? Define the API to accept only integers and require a caller who has a string to first convert it to integer.

View on HN

The example of "integer vs. string" is too low-level to explain why algebraic data-types are useful. It's much more valuable when trying to model a particular domain.

As a concrete example, consider assembly: often you can either provide a number directly ("immediate" mode) or refer to a register for a value ("register-direct" mode). You could model this as a product of <mode, value>, but the way you interpret the value depends on whether it's meant to be an immediate value or a register name. We get lucky in that registers and immediates are both numbers, but there's no reason that has to be true a priori -- perhaps we have a gloss on our assembly that treats register names as strings.

Moving up a level, the set of all instructions is also a natural sum type. You provide different kinds of arguments depending on which instruction you intend to invoke. In general, when the _type_ of things may depend on the _value_ of a tag chosen from some fixed family ("immediate" vs "register", or choice of instruction), sum types are a really good option.

Scott Wlaschin has a nice series of posts on domain modeling with types: https://fsharpforfunandprofit.com/series/designing-with-type... . I can also highly recommend his book!

I think maybe you are approaching this from the wrong perspective. Instead of asking what can I use sum types for, it might be useful to ask, what is the shape of existing data? As it turns out, most systems contain either implicit or explicit sum types. Take JSON, for example. A JSON value can be defined as sum type of null | boolean | number | string | Array<JSON> | Object<JSON>. Types are useful way of describing characteristics of domain you are working in.

Interpreting JSON is a good concrete example. But I wonder if that hints at that sum-types are mostly good for writing interpreters (and compilers).

Another good example mentioned is nullable types. It seems null is so important that many programming languages have built-in support for it. So it seems null-types make null unnecessary. (?)

I can also see that sum-types are useful for modeling data. But are there any (relational or otherwise) databases which have support for sum-types?

I mostly do iOS work, and I find ADTs useful for representing UI state machines.

For example, if I have a view controller (screen) that async loads data, I can have an enum State (in Swift enums have associated values), with the following cases:

- An initial state with nothing - A loading state that contains the associated Promise that represents the network request (which I can cancel) - A fully-loaded state with the data model I got back from the network - An error state containing an error object I can display to the user

Also, the most common use case for an ADT in Swift is representing Optional, which is when you have a nullable object.

ADTs allow you to more bring more of your problem domain into the compiler, which reduces the number of places you need to shim your models.

The idea is to disallow altogether construction of invalid states, so you don't even need to write logic to catch bad data instances, or "convert integers to strings" (god forbid :-p). [1] gives a typical example of how this modeling may look like.

I think something like typedefs could be great in providing this kind of data modeling capabilities in languages where it ADTs are more tedious to write by hand.

1: https://fsharpforfunandprofit.com/posts/designing-with-types...

If you only think in bits, each extra bit you allow doubles the number of represetable combinations. Eg one bit allows for two values to be represented: on/off, true/false, yes/no, light/dark...

Now if you have more than two states you want to encode you need at least one additional bit. Eg two bits allow for four different states (00,01,10,11). But that way (adding a bit, or highler level a field in a struct/tuple) your numbr of possible states grow exponentially.

What if you have exactly 3 states you want to represent (eg small/medium/largem, up/down/mute or x/y/z) or 6 (not a power of two) states? The way you encode the states by combining bits you allow for more states to be encoded than are actually valid. So you allow invalid states. Eg for ["00"~small, "01"~medium, "10"~large] you can not decode "11".

The way combining bits works can be though of as product data types. The number of possible combinations get multiplied when composing data types.

Now sum types enable you to define number of states which are not-power-of-two by summing the possible combinations when composing.

Algebraic data types combine product and sum types so you can define set of encodable states as the exact number of actual valid sates you want your system to have.

Reply on news.ycombinator.com