
Monads explained by Eric Lippert - tucaz
http://ericlippert.com/2013/02/21/monads-part-one/
======
DannoHung
Monads are complicated because the word "monad" bears too much weight in any
discussion about them.

1) There is a category theoretical concept of a monad. This is largely
irrelevant in a practical explanation of monads since Monads are usually
talked about in terms of another category theoretical concept called the
Kleisli Category or Kleisli Triple. However, if someone starts talking about
"monad laws", they're probably referring to the theoretical sense of this.

2) There is, in Haskell at any rate, a typeclass called the Monad (note the
capital "M"). This is mostly important because when a type is an instance of
this category, the Haskell do-notation is useful. Aside from that, you can
only use the handful of operations that the Monad typeclass implements that
you don't have to implement yourself for it to be an instance of Monad.

3) There are Monad type constructors, such as Maybe, IO, and State. This is
where things actually start getting interesting for the practitioner, because
each provides a specific abstraction of a concept, such as input/output or
partial functions (IO and Maybe, respectively).

4) There are Monad types, both abstract and concrete, like Maybe a, IO a,
Maybe Int, State MyType and so on. These are the types you actually will
program with.

5) There are Monad values, which are instances of the Monad types, which are,
themselves, instances of the Monad type constructors, which are instances of
the Monad typeclass.

6) Then just to add a slightly extra confusing layer on top of it all, you
have the values _inside_ the Monad you'll actually be doing computations with.

7) And finally, it doesn't help when in code examples, type variables and
function variables are conflated by name, such as in:

    
    
        get :: State s s
        get s = (s,s)
    

Unfortunately, that's much more clear for an expert than a beginner in regards
to what's going on there, so if you're reading code samples, likely written by
people with expertise, they're going to be confusing.

So, yeah. Simple concept of explicit effects. Seriously semantically
overloaded stack of terms to actual reason with them about.

~~~
Peaker
Minor nitpicks:

"Monadic types" and "Monadic values" would be better for 4 and 5, because
"Monad types" are the type constructors (which are also sometimes named
types). And "monad values" is not a term I've ever heard used.

Also, values have-type, they're not instance-of. So it would be slightly more
accurate to say monadic values are values of a monadic type, whose type
constructor is an instance of the Monad type-class.

I agree better and more accurate use of accepted terminology for all these
concepts could be useful.

As for the namespacing issue in the examples, it might be confusing for a
complete beginner, but one of the first things you learn in Haskell (ideally
before Monads) is how scoping works.

~~~
DannoHung
I'm sure I've made some terminology decisions that are questionable, but in
light of someone writing the community approved guide to talking about monads,
I'll try to explain what I was trying to get across.

First, I was trying to emphasize that a type constructor is not strictly a
type in the sense of a value having a type. While we commonly speak about to
the parameterized types without their type arguments, they aren't really
"types" in the type theory sense while there are still type arguments to be
supplied. That is, "Maybe"'s kind is * -> * while Maybe a's kind is * even
though a is a generic type.

When referring to something as a "monadic value" I was just trying to
emphasize that the monad that contains a value is itself a value in the
Haskell runtime system and that such a "monadic value" is separate from the
value contained there within.

Finally, maybe this is a bad habit of mine, but I've always referred to values
as instances since they inhabit types.

I disagree that the namespacing is only ever an issue for a complete beginner.
The visual separation between a type expression and a value expression in
Haskell can be pretty thin. It's not just about whether they are unambiguous
but how much attention you have to pay to while you're skimming code.
Honestly, I don't think there's much that can be done about it, but it's just
the cherry on top for beginner and intermediate users. Especially ones who
aren't using Haskell regularly.

------
ufo
Note that this is a series of posts. The first post that is being linked to
doesn't have much IMO.

<http://ericlippert.com/2013/02/21/monads-part-one/>

<http://ericlippert.com/2013/02/25/monads-part-two/>

<http://ericlippert.com/2013/02/28/monads-part-three/>

I wasn't clear for me but in the last post he mentioned that there would be
more posts to come.

~~~
dons
He sure takes his time..

 _Episode 4: Conclusion: But we are so close! Next time on FAIC we'll make a
small but vital modification to the signature pattern ApplyFunction to arrive
at the actual second requirement of the monad pattern._

~~~
Locke1689
Eric is attempting to explain it to a wide class of C# developer -- most of
whom are pretty unfamiliar with lambdas and higher-order functions, much less
eclectic type polymorphism and computation.

------
arianvanp
Monads should be a familiar concept for the seasoned C# programmer. LINQ's
'from in' syntax and the haskell monad 'do' syntax are almost the same!

Heck, the type signature of SelectMany and (>>=) are even the same!

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

and

    
    
        public static IEnumerable<TResult> SelectMany<TSource, TResult>(
        	this IEnumerable<TSource> source,
        	Func<TSource, IEnumerable<TResult>> selector
        )
    
        m = IEnumerable
        b = TResult
        a = TSource
    
        =>   m<a> SelectMany<a,b>(this m<a> source, Func<a,m<b>> selector)
    

The type signatures are _EXACTLY_ the same. This isn't a coincidence. LINQ is
actually a monad :)

So I think taking this approach to explain the Monad voodoo to a C# programmer
is the way to go. He actually uses them already :)

~~~
chadzawistowski
Further proof for my personal conviction that C# is a very interesting,
progressive language which masquerades as a Java clone.

I once copied the style of a maybe monad using LINQ - the WinRT apis lack a
"FileExists?" method, so I used LINQ to search a directory's contents for a
filename. An IEnumerable of size of zero represented None, and size one
represented Some.

Unfortunately, a simple try/catch around an attempt to open the desired file
was more efficient and clearer to understand.

~~~
krallja
LINQ has an .Empty() extension method, and you should use that instead of
.Count()==0 when determining if an expression is empty.

------
daniel-levin
Monads are actually a very simple concept. They're really hard to understand
at first because of how much knowledge is prerequisite. I found that by
teaching myself Haskell incrementally, in small steps, I was able to
understand monads just as easily as anything else. For me, it was simply
resolving the following dependency graph:

Algebraic data types -> type classes -> functors -> applicative functors ->
monoids -> monads.

I need to emphasise that understanding of each stage is predicated on
understanding of the previous stage. Trying to learn monads without
understanding these other concepts is like trying to learn Maxwell's equations
without an understanding of calculus and physics.

Lippert states: "Plenty of developers have used the monad pattern entirely by
accident, not realizing that they're re-inventing something that already has a
name.". This is completely true. For instance, watch this video on refactoring
by Ben Orenstein [1]. He 'destroy[s] conditionals with a NullObject'. This is
exactly how the maybe monad works.

[1] <http://www.youtube.com/watch?v=DC-pQPq0acs>

~~~
lucian1900
Learn You A Haskell teaches precisely in that order and I've found it worked
great for me. I was never confused and at every step it was obvious why the
concepts were useful.

------
kinofcain
I'm beginning to think that all the people who have ever understood monads
have written an article trying to explain them.

~~~
DanWaterworth
I understand monads and use them everyday, but I've never written an article
about them. I did once try to explain to someone what a monad is... that could
be the reason I've never tried.

~~~
paulrademacher
You should write an article!

~~~
DanWaterworth
I'll start with the continuation monad, explaining that via the Curry-Howard
correspondence it is related to a double negative. I'll go on to show that the
continuation monad is more general than any other monad by showing how to
implement some common ones (state, list, IO, coroutines) using it. I'll finish
with a half-baked analogy.

~~~
pekk
Write a program which generates explanations of monads. By the time Haskell
compiles it, it will be provably correct without the need for tests.

------
raverbashing
Do you know what I miss about these explanations?

Technical people can't go straight to the point. They go around, around,
around, going into corners, etc

(not only on explanations, mind you)

For example, math has some very high-level/generic explanations, and
curiously, I find them more understandable.

So, I've given up on understanding Monads (or at least Haskell ones), I'll
probably understand them when I come up with a similar problem and think about
how to solve them.

~~~
gngeal
"For example, math has some very high-level/generic explanations, and
curiously, I find them more understandable."

That's because math always "goes straight to the point". There's nothing but
the raw substance in it.

~~~
kryptiskt
When I read math, I really like some motivating examples before digging into
the definitions and theorems. For me, concrete examples makes it way easier to
grasp abstract concepts.

~~~
raverbashing
Oh, I agree, sometimes it's too generic =)

Especially if you don't know the names used in the description.

The problem is that I can't stand explanations that would go like this if it
was explaining Math:

"So, we have a natural number, that is 2, 7, or 34232345 and by the way
they're all integer numbers as well, also they are rational numbers as well,
oh and there's equation you can do with them, but ok, so you can sum those
numbers, etc"

I'd rather go with

"This turns the natural numbers (N, +) into a commutative monoid with identity
element 0,"

------
KirinDave
I tried to like this series. I really did. And it starts out so strong...

The thing is, you can't escape talking about the specific implementation
details of monads while talking about monads, otherwise you lose the plot of
what we're doing and why. Saying, "Monads are just code patterns" is like
saying, "All matter in the universe is just energy patterns," strictly correct
but unhelpful for any true insight.

Its okay to skip the monad laws at first, but what's not okay is to talk about
why there are so many Monads or what actually constitutes a monad. The best
writing I've ever seen on this subject is from Learn You A Haskell for Great
Good, where they walk you through a piece of code and then show how using a
monad _makes it cleaner and less tedious_.

By the end of those 2 chapters from LYAH, you end up with the sense that
monads are obvious and natural. And they are once you understand the sorts of
problems they solve. I wish we had more of that.

------
charlieflowers
As a C# developer, here's the explanation that made it all crystal clear to
me: <http://stackoverflow.com/a/2484101/80112>

------
qznc
Why do you need to understand monads? Nobody explains groups to people using
integers, either.

~~~
Scriptor
You've never been curious about something you don't know about, but don't
immediately need?

~~~
qznc
In general the Haskell community seems way too obsessed about monads. I just
checked the "official" tutorials [0]. I was happy to see they all introduce IO
without talking about monads. However, the linked wiki page has a whole
section about monads. In contrast, there nothing about concurrency or
transactional memory, despite that fact that this is one of the strong parts
of Haskell.

<http://www.haskell.org/haskellwiki/Tutorials>

~~~
papsosouid
>In general the Haskell community seems way too obsessed about monads

You need to understand monads to do anything beyond trivial exercises. It is
something that virtually every single person coming to haskell from another
language is unfamiliar with. I don't see how a focus on such a fundamental
aspect of the language is a bad thing.

------
Surio
@DigitalJack's comment [<http://news.ycombinator.com/item?id=5325542>]
reminded me of another talk on monads viewed by me recently, by none other
than dear ol' Dougie!

[http://www.yuiblog.com/blog/2012/12/13/yuiconf-2012-talk-
dou...](http://www.yuiblog.com/blog/2012/12/13/yuiconf-2012-talk-douglas-
crockford-on-monads-and-gonads-evening-keynote/)

------
kybernetikos
I've also (sorry!) written a blog about understanding monads as a design
pattern [http://kybernetikos.com/2012/07/10/design-pattern-wrapper-
wi...](http://kybernetikos.com/2012/07/10/design-pattern-wrapper-with-
composable-actions/) It was motivated after I'd written a simple promises
library and suddenly realised that promises are monads too.

------
lhnz
The simplest explanation of Monads I've ever read (as a Python developer) was
actually one in a comment by a Hacker News user 'frio':

<http://news.ycombinator.com/item?id=4960701>

~~~
runT1ME
That is an incorrect explanation fyi...

~~~
lhnz
Dammit, how wrong?

------
serpi
The monad is the clitoris of programming.

~~~
marco-fiset
What is that supposed to mean ?

~~~
treerex
I took it as a reference to the clitoris being "Nature's Rubik's Cube" --- the
most difficult puzzle in the world. Pretty funny, actually.

