Monads in Haskell (followup to Haskell Workshop)

Translated to English by @hdgarrood. There might be mistakes. Any remarks I've
made are in square brackets.

This short article should briefly outline how monadic IO works in Haskell, as
a follow up to the Haskell Workshop. TL;DR:

A value of type IO a is a description of an IO action, which could be
performed by the runtime environment (and thereby cause some side effects
and eventually produce a value of type a).

The meaning of a Haskell program is determined by setting main to a
description of an IO action. This action is then performed by the runtime
environment. Other actions are not performed.

Descriptions of IO actions can be combined with each other with >> and
>>= or do-notation. The >> operator is like a line-ending semicolon in
other languages.

If you only want mutable state, you don't need the IO monad. You can thread
state through by hand — or use the convenient abstraction, the State
monad.

The problem: incompatibility with referential transparency

In many programming languages there is a function like readFile :: FilePath -> String, which reads in a file and returns its contents. Such a function can not exist in Haskell, because in Haskell the principle of referential transparency holds: like in mathematics, functions must produce the same outputs given the same inputs. The return value of readFile "foo.txt", however, depends on the current contents of the file "foo.txt".

In Haskell the principle of referential transparency is held in high regard,
because it enables us to understand code locally [not 100% sure about this bit]
and to restructure it easily. Whenever you spot the same subexpression in two
places in the code, you can replace them with a single variable, introduced
via let ... in ... or where .... Without referential transparency this
doesn't work:

because foo() could trigger side effects, which would then be performed just
once as opposed to twice (for example, posting something on Twitter), or depend
on mutable state (for example, the number of nanoseconds elapsed since the
program start).

How, therefore, can we reconcile the wish for referential transparency with the
necessity of performing IO?

The solution: monadic IO

In Haskell — after a few suboptimal solutions and missteps — the
concept of monadic IO was come across, which comprehensively solves the
problem. It has an elegant mathematical background, which you don't need to
know to use it. Here is program which amicably greets the performing
Lambdroid[?]:

main = do
putStr "Hello! What is your name? "
name <- getLine
putStr "That's a nice name. Here it is backwards: "
putStrLn $ reverse name

The types involved are getLine :: IO String and putStr :: String -> IO ()
[note: putStrLn is also String -> IO ()]. The constant main has the type
main :: IO ().

What is happening here? It's still the case that Haskell functions can't cause
side effects such as interaction with the terminal. Haskell functions can
however theoretically describe[?] IO actions. The meaning of a Haskell
program, in this sense, lies in the description of a particular IO action - the
one named main. This one is then performed by the runtime system.

Just as a value of the type Tree a is a Tree, whose leaves are of the type
a, a value of the type IO a is a description of an IO action, which in
principle could be performed by the runtime system, and would thereby cause
some side effects and eventually produce a value of the type a. Such
descriptions are "first class values"; they can be manipulated and placed
inside data structures, without immediately being performed during program
execution. Indeed, only one description is performed: the one which carries the
name main.

The following code example should emphasize this point.

main = seq (putStrLn "abc") (putStrLn "def")

The function seq forces the evaluation of its first argument — when
seq x y is evaluted, first x is evaluated, and then y is returned. For example, seq (fib 10000) "Curry" is semantically fully identical to the constant "Curry", but slower in its execution.

In any case, during execution of this program, the following happens: first
putStrLn "abc" is evaluated. This produces a description of an IO action,
which, when evaluated, would produce abc in the terminal. This description is
then, however, thrown away. putStrLn "def" produces a description, which
would produce def. This description is ultimately the value of main, and this description is executed by the runtime system.

Construction of complex action descriptions

Pre-implemented functions like putStrLn :: String -> IO () or readFile :: FilePath -> IO String produce certain primitive descriptions of IO actions.
The majority of programs will have to make use of several of these primitive
actions. We must therefore have the capability to combine several action
descriptions into one complex description — just as [approximately?] the
constructor Fork combines two subtrees into one larger one.

For this purpose, in fact, we have several possibilities:

The operator (>>) :: IO a -> IO b -> IO b takes two action descriptions. If
the resulting description m >> n is executed, then first m is executed
(and its result of the type a discarded) and then n is executed.

In many cases we would like to make the second action dependent on the result
of the first. To do this, there is the operator (>>=) :: IO a -> (a -> IO b) -> IO b. The action description m >>= f, when executed, does the
following: first, m is executed. The value it produces, x, is given over
to the function f, which generates a further action description, f x.
This is then executed as the second action.

Additionally, there is one more trivial option to produce an action
description: with the function return :: a -> IO a, which (watch out!) has
nothing to do with the identically named keyword in many other languages (for
early exiting of a subroutine). Instead, return x is an action description,
which, when evaluated, causes no side effects and then produces the value x.

The expression return x >> m can be simplified to just m. Both expressions
descripe exactly the same action. Also, return x >>= f is identical to f x.

Finally, the Functoriality of action descriptions should be mentioned. If
m :: IO a is an action description, which produces a value x of the type
a when evaluated, and if g :: a -> b is an arbitrary function, then fmap g m :: IO b describes the action, which executes the description m, whose
result x it then feeds in to the function g and thereby produces the value
g x :: b.

For historical reasons, you can write fmap g m instead of liftM g m. Both
expressions describe exactly the same IO action.

Do-notation

Haskell facilitates dealing with action descriptions immensely with
do-notation. It is pleasant syntactic sugar for the operators >> and >>=.
The introductory example is written as follows without do-notation:

A pitfall with return

The following code contains a type error:

main = do
eman <- reverser
putStrLn eman
reverser = do
name <- getLine
reverse name

The problem is in the line reverse name. When do-notation is used, each line
(excluding pure parts using let) must be an action description, as these
lines will eventually be combined into one large description behind the scenes
with >> or >>=. The expression reverse name is however a simple list, not
an action description. The remedy is to use return:

More idiomatically, we could write the program as follows, by the way:

main = reverser >>= putStrLn
reverser = fmap reverse getLine

The State monad

In Haskell there are no mutable variables. They must be emulated: a function,
which wants to modify a particular variable, can simply return the new value to
the caller. Then, in subsequent function calls, the new value must be used.
Concretely, an example could look like this:

Through this manual threading-through of state, mutable variables can be
recreated. However this is not nice! And, moreover, it is error-prone. In particular, the compiler can't protect us if we switch the intermediate states; for example, if we wrote f3 s' y instead of f3 s'' y.

The State monad is the remedy. The following code is much more comprehensible:

A value of the type State s a can be imagined as the description of an
action, analogously to IO: one, which via access and potential modification
of a state of type s, produces a value of type a.

Primitive state action descriptions are put :: s -> State s () to set the state, and get :: State s s to read it.

Such a description can be executed with the function runState :: State s a -> s -> (a,s), when we specify an initial value for the state. This is different to the IO monad: only the runtime system is capable of executing an IO action. State actions, by contrast, can be executed inside Haskell.

Incidentally, it's not particularly common to need mutable variables in
day-to-day Haskell use. An alternative solution without mutable variables is
almost always more elegant and maintainable. If you're inclined to programming
imperatively, it pays off to invest some effort in finding stateless
implementations.

More monads

Necessity is the mother of invention: after the usefulness of the monadic
approach for IO was recognised, many more useful monads were discovered and designed.

Occasionally we can even program polymorphically with monads. That is, the
previously mentioned control structures forever, replicateM, and forM
make sense not only in the special case of the IO monad, but also for every
other monad.

This comment has been minimized.

Sorry for not returning to you sooner. I improved the wording in a very small number of places (and in that process also changed the German original a bit): See the fork at https://gist.github.com/iblech/429652a31b05e408262b. Feel free to incorporate the changes (unfortunately there are not pull requests with gists) and/or remove the "secret" flag of the gist. Cheers and thanks again!

Sorry for not returning to you sooner. I improved the wording in a very small number of places (and in that process also changed the German original a bit): See the fork at https://gist.github.com/iblech/429652a31b05e408262b. Feel free to incorporate the changes (unfortunately there are not pull requests with gists) and/or remove the "secret" flag of the gist. Cheers and thanks again!