Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Successfully reported this slideshow.

Like this presentation? Why not share!

No Downloads

Total views

1,215

On SlideShare

0

From Embeds

0

Number of Embeds

593

Shares

0

Downloads

5

Comments

0

Likes

1

No embeds

No notes for slide

- 1. Monad as "Things to Do" Yuji Yamamoto 2015-05-24
- 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...

No public clipboards found for this slide

Be the first to comment