Functional Containers Summary: Functor vs Applicative vs Monad
In this text, the final summary of my categories theory series, I will use my spotlight and take a closer look at the relations between all three previously described functional containers, namely: Functor, Monad, and Applicative.
Below, you will find a comparison of them in terms of:
- Theory
- Laws
- Methods
- Possibilities & Use Cases
Theory
Functor
In category theory, a Functor represents the mapping between two categories.
In software, Functors can be viewed as a util class that allows us to perform a mapping operation over values wrapped in some context. It can also be viewed as an interface proving a certain ability, namely the ability to transform the state of an object. In more functional focused languages like Scala or Haskell, Functor is a typeclass.
There are a few types of Functors. However, their in-depth description and analysis is quite out of the scope of this article, but do not be afraid - I added links to other resources that will help you deepen your knowledge.
Functor types:
There are no good built-in counterparts of Functors in Java and other modern-day programming JVM languages. Nevertheless, they are reasonably easy to implement manually. Probably the best counterpart can be found in the Scala library called Cats or in Haskell.
Applicative
In category theory, an Applicative, also known as an Applicative Functor, is a concept that generalizes a Functor by allowing for operations not just on the values inside a context but also on functions within a context.
It sits between Functors and Monads in terms of expressive power. While less powerful than Monads, Applicatives are more structured than Functors.
By the book, Applicatives do not allow chain operations in the same ways as Monads do - with the output of one operation being the input of the other. On the other hand, unlike Functors, Applicatives allow us to sequence our computations.
Unfortunately, such a relation is quite hard to achieve in the world of software as in the end, the underlay data will end up being used as input for the next.
Monad
In the world of software, we can view it as a wrapper that puts our value in some context and allows us to perform operations, specifically operations that return results wrapped in the Monadic context, on the value.
Monads are mostly used to handle all kinds of side effects:
- Performing I/O operation
- Handling operations that can throw exceptions
- Handling async operations
Another important point is that we can chain the operations in such a manner that the output of an operation at any step is the input to the operation at the next step. Such behavior allows us to write very declarative code with minimal boilerplate.
Contrary to Functor, Monad has quite a lot of implementations built in modern-day programming languages:
- Scala (Option, Try, Either, … and more)
- Haskell (IO, …. and more ),
- Java (Optional, not exactly a Monad, but close)
From both practical and theoretical points of view, it is also the most powerful of all the three concepts. The complete hierarchy of all three in terms of pure mathematical power looks more or less like this, going from least to most powerful:
Laws
Functor
If we want to implement a Functor, our implementation needs to obey two laws: Identity and Associativity
1. Identity
Mapping values inside the Functor with the identity function should always return an unchanged value.
2. Associativity
In the chain of function applications, it should not matter how functions are nested.
Applicative
If we want to implement Applicative, our implementation needs to obey four laws namely: Identity, Homomorphism, Interchange, Composition.
1. Identity
Applying the identity function to a value inside the context should always return an unchanged value.
2. Homomorphism
Applying a function in context to a value in context should give the same result as applying the function to the value and then putting the result in context with the usage of pure.
3. Interchange
Applying the function with context f to a value with context should be the same as applying the wrapped function, which supplies the value as an argument to another function, to the function with context f.
4. Composition
Applying the function with context f and then the function with context g should give the same results as applying functions composition of f and g together within the context.
Alternative Applicative
There is also an equivalent version of Applicative whose implementation needs to obey three laws: Associativity, Left Identity, and Right Identity.
1. Left identity
If we create a new Applicative and bind it to the function, the result should be the same as applying the function to the value.
2. Right identity
The result of binding a unit function to the Applicative should be the same as the creation of a new Applicative.
3. Associativity
In the chain of function applications, it should not matter how functions are nested.
If you would like to take a closer look at the laws of this version of Applicative you can notice that they are the same as the Functor laws. The change in the Identity Law originates from the difference in the setup of both concepts. In particular from the existence of the pure method in Applicative, in a way, we have to check one more case.
Monad
If we want to implement a Monad, we have to obey three laws: Left Identity, Right Identity, and Associativity.
1. Left identity
If we create a new Monad and bind it to the function, the result should be the same as applying the function to the value.
2. Right identity
The result of binding a unit function to a Monad should be the same as the creation of a new Monad.
3. Associativity
In the chain of function applications, it should not matter how functions are nested.
Same as in the case of Applicative, Monads Laws are very similar to Functor laws. What is more, Monad Laws are exactly the same as Applicative Laws, the only difference is the concept described in the Laws, the condition remains unchanged.
The relation between the three in terms of which concepts extends which will look more or less like in the picture below, basically, everything is a Functor.
Methods
To implement any of the structures, you will need a language with generics support as a parameterized type M<T> is a base for any of them. On the other hand, you can just generate the code for all required types via a macro or some other construct but with generics it is significantly easier.
Functor
To implement Functor, you will have to implement only one method:
- map, you pass a function that operates on value in context. This method should have the following signature M<R> (T -> R).
Applicative
To implement Applicative you will have to implement two methods:
- pure, which is used to wrap your value in the Applicative context and has the following signature M<T>(T).
- apply (ap), you pass a function with context, the function then operates on the value in the context. This method should have the following signature M<U> (M<T -> U>).
Alternative Applicative
There is also an equivalent version of Applicative where we are using the product instead of apply.
- product, you pass two different values wrapped in Applicative context and get context with both values in return. This method should have the following signature M<(T, U)>(M<T>, M<U>).
In both approaches to Applicatives, you get a map method with signature M<R> (T -> R) by their definition as all Applicatives are Functors, you.
Monad
To implement Monad you will have to implement two methods:
- unit (of,) which is used to wrap the value in Monad context and has the following signature M<T>(T).
- bind (flatMap), you pass a function that operates on value in context but the result is already wrapped in Monad context. This method should have the following signature M<U> (T -> M<U>).
What is more, Monad is also an Applicative and, by extension, a Functor. It means that we are getting a lot of additional methods for free. In particular, a map method from Functor and apply or product methods from Applicative.
The possibilities & use cases
Functor
The Functor is just a util method. It does not provide anything more than simple mapping of a value inside an arbitrary context.
On the other hand, it is also the simplest and the easiest of all three concepts and can be used almost anywhere where we need to perform operations over the values in the context.
Thought Functors still have their limitations. By its definition, Functor is unable to chain computations. What is more, Functor does not provide a way to flatten the result of performed operations, so we can easily end up with nested types like <List<List<Long>>.
However, the possibility of performing effectfull operations without moving them out of the context is quite a good thing.
Applicative
Going further, we have an Applicative with which we can apply functions in context to a value with context. Additionally, with its product version, we can create a tuple out of two objects within the same context.
Such behavior can be extremely useful in some cases – we can use it to compose multiple effects to one effect, reducing types like List<Future> to more reasonable Future<List>.
That is the reason why Applicatives are a great choice for implementing concepts like parsers, traversables, or composers and any other use case where we need to work with many independent effects of the same type.
What is more, because the Applicative is a Functor we can also apply some operations on such output tuples via the map method.
Monad
Last but not least, we have Monad – the most powerful of all three structures.
Each Monad implementation represents an effect:
- emptiness (Option)
- possible failure (Try)
- result or failure of an operation (Either)
- chain of computations (IO)
What is more, Monad gives us the way to put values in such an effectfull context.
Furthermore, thanks to the flatMap method, we can handle nested return types. This in turn solves the issues with M<M<T>> styled types (Optional<Optional<Long>).
Monad implementation will automatically flatten such types to have only one effect – an operation that the map method from Functor is unable to make by its definition.
Additionally, with Monads, we can perform contextual operations as we can pass outputs of one operation as inputs to another achieving a nice, declarative chain of computations.
Summary
Functional containers are a very useful tool that can be applied to a variety of problems. In my opinion, we should find them a place in our engineering toolbox or at least be aware of them. Just please remember that they are not a silver bullet, and making everything a Monad may not be the best way to write your code.
If you would like to deepen your knowledge of a particular container, here is the list with my articles describing all three of them in more detail.
As a side note, I would like to add that these containers add another nice touch of math to the world of software engineering, which is another good point to like them, at least in my opinion.
Hope that you find my text interesting. Thank you for your time.
Review by Mateusz Borek
