
What a Monad is not - fogus
http://www.haskell.org/haskellwiki/What_a_Monad_is_not
======
jrockway
Also, a Monad is not a "thing", it's a property of a thing. "Monad" is a type
_class_ , not a type.

What follows is that Monads are not containers; you don't store a value in
your Monad, you store it in your List. The List just happens to be a monad.
(Similarly, you can't store a ball inside your "Red", but you can store it in
a "Red Box". The fact that the box is red has nothing to do with its ability
to be a container. If you paint a piece of paper red, it does not suddenly
become a container.)

(Side note: it happens that Monads are Functors, and Functors are logically
containers... but remember, the Monad or Functor instance is not what makes
something a container; something is a container because of its underlying
type. "Monad" is a property possessed by certain containers, just as "Red" is
a property possessed by certain other containers. Oh, and please don't make me
insert a joke about Red/Black trees here...)

Put simply; Monad = adjective, not Monad = noun. It took me like two years to
come to terms with this, but now that I have, Haskell is one of the easiest-
to-use programming languages I know.

~~~
jamesbritt
"Also, a Monad is not a 'thing', it's a property of a thing. "Monad" is a
typeclass, not a type. What follows is that Monads are not containers;"

Thanks for this observation, however you (in your comment) and everyone else
uses the word "monad" as a noun. Hence much confusion.

"The List just happens to be a monad. "

Why not say "The List just happens to be monadic", rather than saying it _is_
a monad?

~~~
jrockway
_Thanks for this observation, however you (in your comment) and everyone else
uses the word "monad" as a noun. Hence much confusion._

I agree with you here 100%. I was confused for years for this exact reason.

I tried avoiding the noun form for a while, but the problem is that while it's
technically correct, nobody "in the know" quite understands what you are
talking about. "Why didn't he just call it a Monad?"

 _Why not say "The List just happens to be monadic", rather than saying it is
a monad?_

I should have.

------
lmkg
I haven't worked much with Haskell, but at first blush, monads to me seem
almost like a perverse functional converse to Greenspun's 10th Law. Haskell is
purely functional, which imposes programing constraints, but of course it's
turing-complete so it can still do anything a procedural language can. In the
limit case, it can use denotational semantics to describe an emulation of a
state-based program. And that's what a monad is (or at least, that's what they
look like to me): a DSL for denotational semantics.

Altogether, that's probably for the better. If people are going to use
denotational semantics to emulate a state-capabale environment, it's better if
the method for doing so is standardized, well-specified, and optimized.

~~~
jrockway
_If people are going to use denotational semantics to emulate a state-capabale
environment, it's better if the method for doing so is standardized, well-
specified, and optimized._

I am not following you here. State is nothing special, except that it is
something made special by most popular programming languages. (Where it causes
lots of fun problems.)

I am also not sure that "Monads" are optimized any more than any other
function application. Monadic state-passing is syntax sugar more than anything
else. (With other languages, state is "something else"; lexical environments,
dynamic environments, and so on.)

~~~
whatajoke
_State is nothing special, except that it is something made special by most
popular programming languages. (Where it causes lots of fun problems.)_

With very elementary design decisions, mutable state is very much manageable
in the most popular languages.

Hiding state maintenance through a monad solves very little, while throwing
performance out of the window. Yeah, you can get performance out of a lazy
functional language, but the hoops you have to jump through are not worth it.

Ocaml is eager functional, and IMHO is a very nice compromise between
expressibility and purity. Now if only its type system was as capable as
haskell, and only if it had multi processor support :(

~~~
loup-vaillant
"Now if only its type system was as capable as haskell"

One of the reasons is precisely the "impurity" of the language. I am referring
to the value restriction, which inserts `'_a` (which means "because of
possible side effects, this value won't have a polymorphic type, sorry")
sometimes when you do partial applications (even ones without any side
effect). It bit me once when I tried to do FRP (Yampa-style) in Ocaml. I
couldn't define some of the operators (time) in a modular way (in terms of
integral) without losing polymorphism.

Another reason has to do with the fact that Ocaml is strict. I tried to define
a mini "batteries" module with purely functional lazy lists instead of
destructive streams (the enumeration). There is simply no way to define map or
filter in terms of fold without losing laziness, or seriously polluting the
type of fold, map, and filter. This can still be regarded as a type system
issue : if strict and lazy types were compatible, as they are in Haskell, it
wouldn't have been such a problem.

------
forkandwait
While I grant that the ML family of languages implements some truly brilliant
ideas, ...

... blog posts like this remind me why I love Tcl/Tk and shell scripting.

It is embarrassing, but I always prefer the raccoon to the panda bear.

