3 ms·

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". Wou

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.

regalaxyLogic 6y ago
Suppose I have an `Order` object with a `paymentDetails` property. Since I accept payments from Paypal, Bitcoin and Credit Cards , the `paymentDetails` object may need to have the following shape: Order { paymentDetails: payPalTransactionId | bitcoinWalletAddress | creditCardPayment } And we can keep going further, where `creditCardPayment` is: CreditCardPayment { number: string expiry_month: string expiry_year: string cvv: string } So having a type system that can say "this property could be of this type OR this type OR this type" is useful when you can't model all your data into one type like int or string
mlex 6y ago
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.
jfb 6y ago
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.
Twisol 6y ago
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-types.html https://fsharpforfunandprofit.com/series/designing-with-type... . I can also highly recommend his book!
catlifeonmars 6y ago
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.
- galaxyLogic 6y ago
  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?
emmanueloga_ 6y ago
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-making-illegal-states-unrepresentable/#making-illegal-states-unrepresentable https://fsharpforfunandprofit.com/posts/designing-with-types...
laszlokorte 6y ago
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.

regalaxyLogic 6y ago

Suppose I have an `Order` object with a `paymentDetails` property. Since I accept payments from Paypal, Bitcoin and Credit Cards , the `paymentDetails` object may need to have the following shape: Order { paymentDetails: payPalTransactionId | bitcoinWalletAddress | creditCardPayment } And we can keep going further, where `creditCardPayment` is: CreditCardPayment { number: string expiry_month: string expiry_year: string cvv: string } So having a type system that can say "this property could be of this type OR this type OR this type" is useful when you can't model all your data into one type like int or string

mlex 6y ago

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.

jfb 6y ago

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.

Twisol 6y ago

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-types.html https://fsharpforfunandprofit.com/series/designing-with-type... . I can also highly recommend his book!

catlifeonmars 6y ago

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.

galaxyLogic 6y ago
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?

emmanueloga_ 6y ago

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-making-illegal-states-unrepresentable/#making-illegal-states-unrepresentable https://fsharpforfunandprofit.com/posts/designing-with-types...

laszlokorte 6y ago

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.