Monad as "Things to Do"

Yuji Yamamoto

2015-05-24

Nice to meet you!

Yuji Yamamoto(@igrep) age 26.

Remember this avator:

Nice to meet you!

Yuji Yamamoto(@igrep) age 26.

Japanese Ruby engineer working at Sansan, Inc.

Hobby Haskeller.

Holding workshop of Haskell (Japanese) per month.

I'm gonna talk about...

Describe Monad in Haskell from a my point of view.

This↓

class Monad m where return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b -- snip. --

I don't know much about Monad in category theory.

Disclaimer: it'd sound too natural for people who already know

Monad.

In short,

I got fairy sure of Monad in Haskell by interpreting it as

"things to do every time a function returns a value."

Monad is a type class

Like this (reprinted) ↓

class Monad m where return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b -- snip. --

Recall what a type class is:

something like...

Interface in Java and C# etc.

Module providing mix-in in Ruby.

=> Provides a way to put types with same behavior

altogether!

Why type class is useful

When creating a type, get various functions available for the

type class

only by defining the required methods.

The only thing to do is to write all the computation unique to

the new type in the required (undefined) methods!

Then, how about Monad?

By defining only return and >>= method,

do notation available!

And more!

Write only computation unique to a new Monad (its instance)

in the required (and undefined) method!

Let's see >>= method!

(>>=) :: m a -> (a -> m b) -> m b

Like the other type classes, Monad abstracts types

by defining the unique computation in the required >>=

method.

Let's see >>= method!

(>>=) :: m a -> (a -> m b) -> m b

For example...

In Maybe, >>= checks Just a or Nothing

before passing a of m a to (a -> m b).

In Reader, >>= supplies the missing argument to the reader

function

before passing a of m a to (a -> m b).

In Parser, >>= consumes the given string

before passing a of m a to (a -> m b).

Let's see >>= method!

(>>=) :: m a -> (a -> m b) -> m b

In both types,

>>= has some required computation

to pass a of m a to (a -> m b).

In addition,

>>= is implemented so that

the required computation can be repeated by passing m b of

(a -> m b) to another function.

In other words,

Monad's >>= has all things to do

in the part of passing a of m a to (a -> m b)

Monad assigns >>= things to do

to pass a value (not wrapped by a Monad) to a (a -> m b)

function

each time the source (a -> m b) function returns a value.

That is!

Monad is useful

when you have many functions of type (a -> m b) with things

to do.

For example!!

For functions that force you to check if successful each time

executing.

=> Maybe Monad

For functions that force you to append the result log each

time executing.

=> Writer Monad

For functions that force you to make a side effect (e.g. I/O)

each time executing.

=> IO Monad

Then, what's the merit of this idea?

I've seen many metaphors describing Monads (in Japanese),

But all of them are too abstract to grasp.

Then, what's the merit of this idea?

By contrast, "things to do each time a function returns a

value" makes

it easier to imagine at least for us programmers (probably).

it possilbe to describe Monad based only on its property as a

type class.

them find Monad's merit more naturally.

Especially for those who are careful about DRYness

by telling "Monad packs things to do every time into one method".

it unnecessay to classify Monads into smaller kinds.

e.g. "failure monads", "stateful monads" etc.

Conclusion

Monad in Haskell is a type class.

Type classes abstract types with same behavior.

Monad abstracts "things to do each time a function returns a

value".

Thus, I've appended a new page of the history of the

numerous Monad tutorials...