Yuji Yamamoto

2015-05-24

- Yuji Yamamoto(@igrep) age 26.
- Remember this avator:

- Yuji Yamamoto(@igrep) age 26.
- Japanese Ruby engineer working at Sansan, Inc.
- Hobby Haskeller.
- Holding workshop of Haskell (Japanese) per month.

- Describe Monad
**in Haskell**from a my point of view.- This↓

- I don’t know much about Monad
**in category theory**. - Disclaimer: it’d sound too natural for people who already know Monad.

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

“*things to do*every time a function returns a value.”

Like this (reprinted) ↓

- something like…
- Interface in Java and C# etc.
- Module providing mix-in in Ruby.

- => Provides a way to put
**types with same behavior altogether!**

- 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!

- 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!

- Like the other type classes, Monad abstracts types

by defining the unique computation in the required`>>=`

method.

- 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)`

.

- In

- 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.

- 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.

- Monad is useful

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

with*things to do*.

- 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**

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

- But all of them are too abstract to grasp.

- 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”.

- Especially for those who are careful about DRYness
- it unnecessay to classify Monads into smaller kinds.
- e.g. “failure monads”, “stateful monads” etc.

- 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…