I recently attended the “Introduction to Scala” course at Working Mouse. The course was run by Tony Morris with the help of Tom Adams. I had feared that the course would be a introduction to Scala with Haskell-coloured glasses … and it was just that. However, it was just this that made it interesting. I already know Scala at a basic level so a truly introductory course would have offered little. I knew that Tony was into Haskell and on one hand I wanted to come away with an idea of what a monad was and on the other hand I didn’t want to learn Haskell with Scala syntax. Luck would have it that there turned out to be just two attendees – myself and John Ryan-Brown. Tony was able to accelerate through the introductory material with help from Tom Adams. This freed us up to begin working on monads and emulating type-classes in Scala. It was a really wonderful course that I can’t do justice to in this short post. I did come away knowing what a monad was (but now I’m not quite so sure). I did learn Scala through “Haskell glasses” but that was what was really wonderful about the course.

So what are monads? Well it appears to be an “ultimate interface” with 3 special methods – return (also called unit), bind and join (where join can be derived from return and bind). My current understanding is that monads are the “ultimate iterator” but I figured I’m supposed to understand that they are an “abstraction over computation”. This is going to take a while to sink in. Here are the signatures for the 3 special methods:

return: a -> Ma

bind: M a -> (a -> M b) -> M b

join: M (M a) -> M a

In terms of List, return is cons, bind is flatMap and join is flatten. I wasn’t familiar with flatMap but it’s a more general version of map. Map can be implemented in terms of bind/flatMap and unit/cons.

List(1, 2, 3) map (n => n + 1)

List(1, 2, 3) flatMap (n => List(n + 1))

Since then I’ve been learning a little more about Haskell and Category Theory. It’s really great to have a new avenue of things to study. Haskell certainly has come a long way since I looked at it last.

Oh and the title of this post… Well it’s kind of a bad joke from day 3. After 3 days of indoctrination I realised that it was leading to the conclusion that a new breed of programmer was required – the hyper-productive monadic programmer for the 21st century. This new breed of programmer would eschew side effects and even OOP in preference to algebraic data types, type classes, implicits, higher order functions, monads and higher kinds. They would impress their friends with deep knowledge of mathematical principles and have an IQ 50 points above decent developers of today. These programmers would be trained to be 10x more productive than their imperative colleagues (coding in Java and C#) – allowing some of us to retire for a better life (perhaps as an economist or financial advisor). All that remains is to work out how much of this is hyperbole and how much sound.

A few technical notes…

The type signature for return is a->Ma, with a lowercase “a”.

All that is required for a monad is return and bind. Join is actually definable in terms of bind.

join x = x `bind` id

These functions also need to obey the “monad laws”. Otherwise, they aren’t magical.

The return function on lists isn’t just “cons”. It’s “cons with the empty list”. In other words, it maps x to [x], the singleton list containing x.

Category theory is overrated =-X

Monads really are magical, though.

> The type signature for return is a->Ma, with a lowercase “a”.

A typo. fixed.

> All that is required for a monad is return and bind. Join is actually definable in terms of bind.

I did mention that.

> These functions also need to obey the “monad laws”. Otherwise, they aren’t magical.

Tony did mention some laws. I must have forgotten them. I wrote down a note about identity and composition applying to something we called fluffyMap in class. Hmmm seems these were just laws for map (not flatMap etc). If they’re similar to the ones for map then they must be pretty intuitive :).

> The return function on lists isn’t just “cons”. It’s “cons with the empty list”.

Ah yes, that’s true. In fact it is somewhat surprising to me that the “magical interface” doesn’t include a function “empty”.

For ’empty’ you want a monoid 🙂 Take a look at http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html, in particular, click on the ‘Source’ links at the right of the page.

Thanks Ben. The paper that the code refers to is going to be very informative

http://citeseer.ist.psu.edu/jones95functional.html

but is currently quite perplexing 🙂

After hunting around in the Haskell library docs, it looks like MonadPlus is closer to providing what I was thinking of as “empty”. The method is called mzero. It appears to be related to the Monoid but it “extends” a Monad.

http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Monad.html

All this is very abstract for me. I am working through Real World Haskell but it’s slow going as the first few chapters are very basic.