Edit: The book was enjoyable and a delight to read, but I started struggling to keep up from Chapter 8. as it went into Monoids and Monads, I feel like I need to read other tutorials before coming back to it.
Don't read the "Monad tutorials" and especially do not stop programming in Haskell until you "learn monads". Find one of the respected books, read it and do the exercises.
You do not need to thoroughly understand monads in order to do some IO programming just like a violinist does not have to understand the physics of vibrating strings or you don't need to be an auto mechanic to drive to the grocery store.
Write the "Guess the Number" game in Haskell using IO and you should understand the basics and that gets you far. Reading and writing to/from files and network sockets, etc works pretty much the same as you're used to from imperative programming languages. "Guess the number" contains just enough control flow (repetition, conditionals) to get you started.
I've written tens of thousands of lines of Haskell code, including production code at work, and I still don't know what a Monoid is. I have only a faint theoretical understanding of monads, but I am fluent writing IO code and applying monads to other problems like parsing and error handling.
You should only study monads when you're fluent doing some basic imperative programming in Haskell or if you are a math student and have a keen interest in category theory.
I agree completely that it's not necessary (and maybe even detrimental) to learn monads to use Haskell's IO, but I think this claim is dubious. Not too many imperative languages have lazy IO and this feature can be a surprising hurdle for the Haskell beginner who is versed in other languages.
That is surprising. They show up all over in fairly common libraries - for instance, Writer collects a monoidal value. The very simplest notion is "monoid is for things you can combine". Taken from math, a monoid is a set of things (a type) for which you have an operation (called mappend in Haskell) which you can combine associatively, where the set contains an element (mempty in Haskell) that is an identity with respect to that operation.
Some common monoids are:
Anything list-like:
mappend appends two lists
mempty is the empty list
Integers over addition (newtype Sum)
mappend adds two integers
mempty is zero
Tuple of monoids:
mappend is componentwise mappend
mempty is (mempty, mempty)
Functions where the domain and range are the same:
mappend is function composition
mempty is idMy advice is to use the language until you gain an intuition for them. Despite being rather simple, I found it was difficult to fully appreciate them without a decent amount of exposure. Really though, monads aren't what Haskell is all about, and don't let an incomplete understanding of them stop you from diving in.
[1] http://www.reddit.com/r/haskell/comments/2vm0ed/is_there_a_g...
http://homepages.inf.ed.ac.uk/wadler/topics/monads.html
http://homepages.inf.ed.ac.uk/wadler/
Alternatively, if you really are allergic to LaTeX, or beards, the recently Oscared sigfpe’s “You Could Have Invented Monads! (And Maybe You Already Have.)”
http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
There are no other monad tutorials. Just forget about them.
No, that is one use for Monads. A Monad is just something that has a bind (>>=) function and a return function.
I don't mean that as any sort of "gotcha", just some additional clarification - especially if people read your "just" too strong.
You realise that this is the most useless description ever? While I'm sure it's right, it doesn't actually mean anything. Why's it a good abstraction for doing <X>, better than any other abstraction? If it abstracts over a gazillion different things, why not have special-purpose abstractions like other languages (and thus probably make the language a lot simpler to use)?
Your description is on the same level as "programming languages are structured text".
> A Monad is just something that has a bind (>>=) function and a return function.
?
(I know how they relate, but the above assertion is not a particularly helpful description of List and Maybe)
Good. If my description of a Monad was a good description of List or Maybe, then I described Monads wrong.
Your complaint is like saying "Your description of a shape was not a helpful description of a dodecahedron." Indeed, a dodecahedron is a very specific instance of a shape.
List and Maybe are indeed the easiest monads, but thinking about them in terms of (>>=) and return doesn't give a good intuition about monads, Lists or Maybe. So I think that wasn't "the point".
"The point" was actually that state and IO aren't the only monads, and that the definition is way more general than that. List and Maybe being the easiest monads is irrelevant.
Which is perhaps why many people have a hard time understanding it. That is, however, the true definition.
>Why's it a good abstraction for doing <X>
That depends on <X>. I can't answer that question unless you tell me what <X> is.
> If it abstracts over a gazillion different things, why not have special-purpose abstractions like other languages (and thus probably make the language a lot simpler to use)?
Why would a special-purpose abstraction be easier to use? If you only understand monads in terms of state, you can just use them that way.
Isn't that kind of the problem? I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for. Is it a good abstraction for adding numbers together? God knows, nobody can explain it.
> Why would a special-purpose abstraction be easier to use?
Because it says what it does on the tin, rather than being buried under several abstraction layers. My for loop is a lot more obvious than your "lifting functions into the list monad" or whatever it is you do with them, and is quite obviously doing an entirely different thing from, say, dealing with the contents of a Maybe, or storing state, or executing IO operations.
We can play with abstractions upon abstractions all day, but unless they actually mean something solid, how are they useful in explaining or solving a problem?
Maybe. Leaving things in the abstract can certainly be confusing sometimes.
>I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for.
I think once you understand Monads for what they are (i.e. accept that it's just something with bind and return), you start seeing where it makes sense to use Monads. Until then, you can just use whatever concrete Monad implementations you're aware of. It seems like you know perfectly well that there exist Monad implementations for Lists, for example.
> Because it says what it does on the tin, rather than being buried under several abstraction layers.
IO, List, and most other Monads do what they say on the tin, even if you're not aware that they're Monads.
You don't have to know if something is a Monad or not to use it. For example, I've been using Lists my entire programming career without it occurring to me that I could use them with bind to model nondeterminism or the ZipList Monad.
>but unless they actually mean something solid, how are they useful in explaining or solving a problem?
They are useful because they are examples of http://en.wikipedia.org/wiki/Algebraic_structure .
You can use the definition of an algebraic structure to prove things about all instances of that structure.
Monads are, in fact, quite useful even in their most general definition.
The GP's explanation of the concrete features (with simple examples!) is one of the most useful explanations of monads I've seen. It isn't complete, but as a gateway to a complete explanation it is extremely good.
A monadic data type is a container that can be mapped and flattened.
- It's a container, because it stores has an inner type, which refers to the data it contains. For example, think of the type parameter that describes the elements of a list.
- It is "mappable" in the sense that its contained type can be converted to another type by providing an operation from the first type to the second type. Imagine converting a list of strings to a list of integers, where each integer is the length of the corresponding string.
- It can be "flattened" in the sense that if its inner type is an extra nesting of the container type, it can be flattened to a just one level of the container type. For example, a list of lists of integers can be flattened to just a list of integers by concatenating the sublists.
- It seems kind of trivial to say, but there has to be a way to construct a container given one of the elements it's supposed to contain.
There are also a couple of rule these operations have to fulfill. They're kind of abstract when stated on their own, but make intuitive sense when you consider examples.
Pretty simple, huh? What's cool about it is that you can assign all sorts of metadata to the container type and semantics to the flatten operation, and you get a nice representation of a pipeline of operations, where each one depends on the all the previous steps. This is basically just imperative programming -- each step depends on the current context and can optionally mutate that context, affecting subsequent steps.
You might ask, "but isn't imperative programming what we're trying not to do?" In the most general sense with mutable state everywhere, yes. But monads give you a way to describe imperative logic in very tightly controlled contexts.
http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...
http://www.stephanboyer.com/post/9/monads-part-1-a-design-pa...