Slides from my talk

[Jed Wesley-Smith]

Well, you aren't getting them, because they're just stolen from this blog which you should read anyway:

http://newartisans.com/2012/08/monads-in-pictures/

After that, you should read Josh Suereth's great "Intro to FP: Patterns in Scala":

http://jsuereth.com/intro-to-fp/preso.html

And if you're still struggling with Monads there are plenty (no really, plenty: http://www.haskell.org/haskellwiki/Monad_tutorials_timeline) of interesting tutorials on them including the "Burrito" comic:

http://chrisdone.com/posts/2012-01-06-monads-are-burritos.html

inspired by the blog:

http://blog.plover.com/prog/burritos.html

cheers,
jed

[Graham Lea]

Thanks for sending those through, Jed, and thanks for your talk. (Sorry I had to sneak out. My bus options are 9:03 or 10:03.)

I felt like I was so close to getting it by the end of your talk, but I still have one gap. I totally get functors, mapping is awesome, and I get that the difference with the Monad is that the lambda produces a Monad instance, not just a value, but I didn't hear a clear explanation of why that's better. I think perhaps you touched on it with your URL encoding example so I'm going to put something out there and you (or anyone else) can tell me if I'm wrong: 

Having the function passed to flatMap produce a Monad, rather just a value, is better because the Monad calling the function does special combining magic with the results. So if you called List.map with a function returning a List, you'd get a List[List[B]], but with flatMap you get combining magic that gives you a List[B] instead. Similarly with a Future flatMapped over another Future-producing function, and again with Option flatMapping over something else optional. So the advantage over functors is not the ability to chain map calls, because functors can do that, but that each flatMap call in the chain can produce a Monad rather than a real value without complicating the type of the end result of the expression. Is that the secret sauce that improves on functor?

Cheers,

Graham. 

--

Graham Lea

gra...@grahamlea.com

[Eric Springer]

Not that I know much about this stuff, but that seems to be exactly the point. You normally want someone to put cheese in your burrito, not someone to put a cheese burrito in your burrito. Or put another way, how useful would an Option[Option[Option[N]]]] be? And what if you had a run-time-determined amount of them to combine etc

[Brian McKenna]

Monads aren't "better" than Functors. All Monads are (Applicative) Functors!

This is because:

def map[B](f: A => B) = x.flatMap(pure compose f)

But not all Functors are Monads. There aren't many examples I can give
except for ZipList. ZipList is an Applicative Functor that lets us do
this:

> getZipList $ pure (+) <*> ZipList [1, 2, 3] <*> ZipList [4, 5, 6]
[5,7,9]

Instead of the usual Applicative on List:

> pure (+) <*> [1, 2, 3] <*> [4, 5, 6]
[5,6,7,6,7,8,7,8,9]

First one we can't write a Monad for. The second one we can.

Anyway, you can't implement a flattening function for any given
Functor - because your only tool is map...

So that's where a Monad comes in. Here's a generic flattening function
for any nested Monad:

def flatten = flatMap(identity)

Can't do that with just map :)

So to answer Eric:

how useful would an Option[Option[Option[N]]]] be?

Not very, if Option only had a Functor.

On Sep 13, 2012 6:24 PM, "Graham Lea"

[Jed Wesley-Smith]

Right, so what this means is that Functor doesn't let us compose multiple things within the context of the particular Monad.

For instance if we are working within Future and all we have is map, we can only do one asynchronous action and then we are limited to doing things with the result (so our Future[A] can become a Future[B]). If though we wanted to say call a REST service with the result of our database query, we'd then have this awkward Future[Future[B]] thing – flatMap lets you avoid this and compose multiple actions.

Another example is List, if all map a List with 5 elements, then you must get a 5 element List out – with flatMap you get an arbitrary size List out.

So, Monad gives you the ability to sequence or compose an arbitrary number of actions within the specific context of that Monad.