I found a post by Qiaochu Yuan that has the following definiton: A comathematician is a device for turning cotheorems into ffee.
Apparently this is a very funny joke. Could someone explain it to me and tell me where I could learn about the subject in question? Thank you very much in advance.
+1 for “Apparently this is a very funny joke”. math.stackexchange.com
Category and Monads
By the way, the above joke has nothing to do with todays topic, I just found it funny.
I had a little bit of a writers block since the last episode in the series about ApplicativeBuilder, since I was not sure how to approach the coming topics. Hence we take a little bit of time to disgress. Semigroups, Monoids, Functors and Applicatives are all concepts found in category theory. Category theory is a very general mathematical theory, but it deals with something which is at the core of functional programming, and hence makes it so attractive for programmers. It is dealing with:
 Abstraction
 Composition
And composition is something which we want to exploit, and there stems our interest in category theory.
What is a category?
In Scala terms the definition of a category is simple:
1 2 3 4 

We have some objects of any type, and we can connect these objects using arrows. So if we have an arrow from f: A > B
and an arrow from g: B > C
, category theory implies that we also have h: A > C
(dashed arrow).
We also need an id
 Arrow: an arrow pointing back to the identical object.
(id arrows ommited)
A category for Scala Types and functions
So  what if we create a category for our Scala types as objects and functions as arrows:
1 2 3 4 

This was as simple as useless, because we already have composition for functions in Scala. Do we really?
One step beyond
Let’s see what happens if we try to compose some fancy functions, like f: A => Option[B]
and g: B => Option[C]
. Well, they don’t compose:
1 2 3 4 5 6 7 8 9 10 11 

Let’s create a small helper class called Fancy, which wraps our fancy methods (this is just a workaround to get a safe way to talk about our fancy functions):
1


Can we create a Category
for Fancy
?
1 2 3 4 5 6 7 8 9 

Hell yeah, we can!
1 2 3 4 5 6 7 8 9 10 11 12 

This was nice. Let’s do it again. This time for List
:
1 2 3 4 5 6 

Well, I cheated a bit by using flatMap
in this implementation. But we could have used flatMap
in Fancy
for our Option
as well. Let’s write the two implementation under each other:
1 2 3 4 5 6 7 8 9 

Hmm, almost the same, let’s abstract over that:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 

We haz Monads!
Some explaining is probably in order:
 the Monad trait is just another typeclass
 the funny construct
({type l[A,B] = Fancy3[M,A,B]})#l
creates a type alias, as if we saidtype FancyOpt[A,B]=Fancy3[Option, A, B]
only, that we need to it dynamically, because only at the time we want to construct the category M is known.  Our
Fancy3
helper class is theKleisli
class in scalaz. It is just a wrapper with lots of helper functions for functions of the typeA => M[B]
But the important thing is, we just constructed a Monad. And if you tried to come to terms yet, what a Monad exactly is: it enables you to compose fancy functions (with some constraints/laws).
Outro
I am neither a mathematician nor particularly good at Category Theory, for more details read the very good blog posts byBartosz Milewski. He helped me get various pieces together, especially seeing many of the constructs in category theory as means to compose things of a special structure.
For further articles in this series: TypeClass101