Ubiquitous Types: Introduction to Algebraic Data Types

Ubiquitous: present, appearing, or found everywhere.

most of the time we as humans are able to recognize and label things in the same way “most probably”. the small example about our ability to do that recently is the most annoying fraud checking system “reCAPTCHA” yeah, the one that’s always asking you to select and label some kind of type in every action we usually do these days on the internet to validate you’re a human.

the model of reCAPTCHA is so easy it just showing to you a type and asks you to select this type from the recommended images.

So labeling things is something we naturally do, we are used to labeling things around us in a way that makes them distinguishable.

the same process happens with programming as well. everytime you think and write a program you almost try to find the similarities between things then you have to label, composing those similarities.

in the Functional programming universe, everything is around functions. the function is simple it's just a small kind of box that accepts input and produces output. input -> output.

the (input -> output) description is called type signature. the type signature is just the definition of the function input and output.

// Signature -> multiplay2 :: Number -> Number
// Which Means that the multiplay2 function takes and 
// expect to pass parameter(input) from type Number and
// produce(output a value from type Number.
const multiplay2 = x => x * 2;

// Signature -> sum:: (Number, Number) -> Number
// Which Means that the sum function takes and expect to
// pass 2 parameter(input) from type Number
// and produce(output) a value from type Number.
const sum = (x, y) => x + y;

So we could define type as:

it’s just a given label or name for some values that could be used as input or output for function.

the insight and understanding of the function from just reading a type signature are powerful. being able to express, recognize the function itself without going into the function details that’s one of the powerful things that type signature provides.

so the type is just a name for any kind of thing that could be used as input or output for functions.

Algebraic Data Types

Wikipedia's definition:

an algebraic data type is a kind of composite type, i.e., a type formed by combining other types.

So basically the algebraic data type is just a composition of types. composition means putting things together so you can combine a couple of things to make a bigger thing.

the common types in algebraic data types are “Product type” which basically represented by “ANDing” things together and “Sum type” which basically represented by “ORing” things together.

Product type:

Product type is a compound for other types. and shortly speaking Product type is just like the “AND” operator. you need every type to make a new one.

type FruitSalad = {
   apple: AppleKinds,
   banana: BananaKinds,
   orange: OrangeKinds
}

The naming Product and equation comes from mathematics, type theory, category theory, Cartesian product

Sum type:

Sum type is a type where your value must be one of the choices types. and shortly speaking Sum type is just like the “OR” operator. you need either this or that type, not both.

type FruitSnack = Apple | Banana | Orange

The naming Sum and equation comes from mathematics, type theory, category theory, Disjoint union

if you’re working with a strongly typed language you will find yourself dealing with composing types and algebraic data types as well.

below is a naive example of composed types:

type Amount = number | string;
type Currency = 'USD' | 'EUR';
type CardType = 'Visa' | 'MasterCard';
type CardNumber = number;

type CreditCardInfo = {
  CardType: CardType,
  CardNumber: CardNumber
}

type Payment = {
  Amount: Amount,
  Currency: Currency,
  CreditCardInfo: CreditCardInfo
}

the main points from this article are to just simplify the concept of Product, Sum types. not meant to implement functions and models around both types might in next articles to write more about how to use both to build types model that works with domains driven.

note: usually the elimination of choices in Sum type needs to implement a matching pattern to eliminate the choices.