A thought about functors and monads

In software engineering, a functor is more than a simple box or container. It is a function that dresses our objects with a computational context and that gives the possibility to apply our usual morphisms (functions, methods, whatever the term used) onto such dressed objects. Maybe and Either are two famous functors. Maybe carries the context that an object can be undefined when applying a computation. Either carries the context that only one object among two possibilities exists (or is valid) when applying a computation.

One thing: a functor F must satisfy the two following properties:

F(id) = id, with id an identity object
F(f(g)) = F(f)(F(g)), with f and g two morphisms.

With functors, we can also apply them on morphism to get a dressed morphism that can be applied later on dressed objects. Those are applicative functors. The applicative functors are then defined by an additional function like this:

apply: A(a -> b) x A(a) = A(b), with A an applicative functors and a -> b a morphism on an object of type a to get an object of type b.

Maybe is an applicative functor.

Monads are an extension of applicative functors. Their interest is to express sequential computation. So we need an additional function in order to apply a morphism onto a dressed object to get another dressed object from an undressed object. This is the bind function:

bind: (a -> M(b)) x M(a) -> M(b), with M a monad

With bind, we can chain monad together to form a pipeline of computation. Maybe is a monad.

For the Kleisli triple I talk a bit in your talk: this is a formalism of three properties that express a monad. In short:

a type constructor with which we can define a monadic representation of a type (a way to build a monadic type)
a unit function that takes an object and that dresses it into a value of the monadic type (the dressed object)
the bind function

k33g / stools

A thought about functors and monads #2