2. Nice to meet you!
Yuji Yamamoto(@igrep) age 26.
Remember this avator:
3. 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.
4. 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.
5. In short,
I got fairy sure of Monad in Haskell by interpreting it as
"things to do every time a function returns a value."
6. Monad is a type class
Like this (reprinted) ↓
class Monad m where
return :: a -> m a
(>>=) :: m a -> (a -> m b) -> m b
-- snip. --
7. 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!
8. 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!
9. 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!
10. 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.
11. 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).
12. 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.
13. 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.
14. That is!
Monad is useful
when you have many functions of type (a -> m b) with things
to do.
15. 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
16. 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.
17. 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.
18. 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...
