I will be necessarily somewhat long, slightly wrong and mostly fuzzy while trying to introducing these concepts in just a page or two...

Monads (and related concepts from category theory, like Functor, Applicative etc) are the next level of abstraction in Functional Programming, beyond functions.

A function is basically a transformation: it turns an A into a B. In functional programming, one can take it and do stuff with it... like composing it with others or passing it to other, higher level functions.

Functions `f : A => B`

allow you to think and program a certain way: the functional programming way, where you can pass functions around to other methods like `sort`

whatnot, such as `list.sortWith(greaterThan)`

. Once you get used to this *functional programming*, you can move on to higher types, higher functions and from there to monads.

There are many advantages to the functional style, my favorite being composability: it allows us to truly think in terms of composable sub-programs.

Functional style is also a perfect match for *reactive programming*.

Read more on functional programming.

Functors `F[A]`

lift a simple function to something more - the signature tells you their secret:

`map[B] (f : A => B) : F[A] => F[B]`

... they essentially gobble up your function f and return something higher level - pause and reflect on this for a second.

This map or fmap, you could think of it as taking a simple unix command like `sed s/Complex/Simple/`

and apply it to something, as in `cat blog.txt | sed s/Complex/Simple/`

.

In scala, you are used to a slightly different version of the same idea:

`List(1,2,3) map (_ + 4)`

Why are they useful? Many reasons

For instance – you are normally ‘forbidden’ from using state between two calls to f – you should know that by now. However, inside a functor you could, for the duration of the entire transformation `F[A] => F[B]`

… you could have some state there… this is the beauty of an internalized iterator versus the one you’re used to. That state would be well encapsulated there in that transformation, so it could be used.

How that transformation is executed, is up to the specific functor you use. Some can optimize it, some can be dumb while some can use state (like cache a DB connection between calls or whatever).

Let’s have a quick random example: I could have my own functor, working on lists, which keeps the elements sorted. If I apply a random function to it, the result has to be also sorted. You can see the problem? my functor will keep it sorted while an externalized loop may or may not keep it sorted, depending on the programmer.

`MySortedList (1,2,3) map (rand(_))`

will always be sorted, while `List (1,2,3) map (rand(_))`

is not…

Without functions and functors, there is no way you could express and enforce that idea – I don’t think…

Read more on functors here.

Monads go even further. Monads have certain laws which give them certain properties which are very useful once you get used to thinking in those terms.

Monads use flatMap rather than map, with a signature

`flatMap (f : A => M[B]) : M[A] => M[B]`

As you can see, they also return a transformation, but a yet higher level one, which includes flattening. But because it includes flattening, it can do it in whichever way it wants. Flattening is essentially to turn a M[M[B]] into a M[B]... but it is not a separate operation, but part of flatMap - now you can figure out the roots of this name, eh?

Why monads are more useful than functors – look at the gobble-able: it’s an `f : A => M[B]`

rather than `f : A => B`

– the **functors limit you to the shape of the functor**, sort of speak – basically if you start with a list of ID’s you will end up with a list of Johns of **the same size** (or more or less, if the functor is cheating, like a Set would).

Monads are one better, you can start with a list of 5 student ID’s and end up with either 45 grades in a school year or 2 missing registrations… yes, `f : A => B`

has to return exactly one and the same B for an A, while an `f : A => M[B]`

could return for instance empty (called unit) he he…

Read more on monads.

The world of monads and functors may be a funny one, especially when it comes to figuring out "who's the monad, man?"...

Instead of

`map[B] (f : A => B) : F[A] => F[B]`

and

`flatMap (f : A => M[B]) : M[A] => M[B]`

You will commonly see these signatures:

`map[B] (f : A => B) : F[B]`

and

`flatMap (f : A => M[B]) : M[B]`

The difference is that the ones we used earlier are a theoretically proper "functor" or "monad", i.e. **decoupled from the underlying collection or shape** while the ones just above use the type constructor of the class it belongs to complete the Functor/Monad. This is what you will see on a Seq or a List or such and it denotes the implicit Functor or Monad associated with that type.

The first set of signatures are necessarily lazy, since they return another function, while the second set of signatures not necessarily - in fact, the second set kind of implies that it's strict - it is up to the M[A] to implement any laziness, if possible.

There’s a lot more to it, as others are trying to convey – try to read as much as you can – there’s no one angle that makes it easy to jump to monad abstractions…

If you are confused by the signatures I used above, it’s ok – no, you don’t have to learn Haskell – there’s an entire series of blog posts to explain the gap...

Note that the random sample above is not kosher, since rand() is not a pure function: it never returns the same B for a given A... but it makes a good point.

Continue the journey by reading the more detailed From function to functor and onto monads.

Consolidating older blogs: this was posted originally on Nov 2012.

See more in:

Viewed **4157** times
(
| Print
) this page.

This content is Copyrighted, all rights reserved.