Zimmer - From Simple IO to Monad Transformers

Consider this example which supposes a function readALine that returns the next line ofinput entered into the console.

If there were referential transparency we could conclude that x equals y . That isn't necessarily true because there is a sideeffect to evaluating readALine . Something changes so that adifferent line is read each time readALine is evaluated. Inthe language of functional programming readALine is calledimpure.

In all three examples we have to think what values our symbols andexpressions represent. In the examples with f , there arecontextual rules to help us. These rules do not vary from programto program. After we become comfortable with them, we don't have tothink about which values of x appear where. The example with readALine is different. In such examples we must always thinkabout how values change as control flows around our source code.

Not having to think consciously about how values change is thereason referential transparency makes a computer program easier toread. But there is a price because referential transparency alsomakes a program more difficult to apply to the real world. Thedifficulty in accommodating a readALine function is an exampleof this.

Thus functional programming provides us with a dilemma. On one handwe like the simplicity and clarity of a purely functional program.On the other we do not like the complications that arise when wewant to do IO or play with other side effects.

This monograph is about Haskell's way of dealing with that dilemma.

To understand how a functional program can handle side effects, think of a side effect as changing something in the world outside of theprogram's data space. Imagine that the world flickersfrom one reality to another as things change. A program which changes theworld then is something like this

Instead of changing the world it makes a new one, flickering fromchange to change on the way.

A Haskell programis a world remaking function whose component parts are worldremaking functions. Here is an example.

The functions be_nice , say_hello , and main can allbe seen as having this type

The function (>>) combines say_hello and be_nice tocreate main . We can view its type signature as

Think of (>>) as then because we are talking aboutone world changing action after another. Leaving aside, forthe moment, precisely how (>>) works, we can understandhow to get sequentiality within a functional paradigm by imaginingthat our program has been defined this way

Only we cannot write it that way because Haskellabstracts the concept of world away from the programmer.

A Haskell programmer is more concerned with creating a program thanwith remaking worlds. In fact, the world is full of things theHaskell programmer ought not be playing with. So it is better to make (>>) apply to some simple data type than to make itrefer to world remaking functions. Haskell provides a parameterizedtype, IO a for this purpose. As an examples

The type for (>>) is

This is much simpler than the version above which uses world remakingfunctions. Moreover this is Haskell.

You may have noticed that IO needs a parameter before itbecomes a real type. Such a thing is usually called aparameterized type. I prefer to think of it as a meta type. Iwill discuss the purpose of this parameter in .

Another way to think of IO is that it is a typeconstructor. Give it an argument and it constructs a type.In sections you will see a use for monad type constructors that take more than one parameter.

The IO meta type is known as a monad. The concept of monad is useful because itemphasizes certain similarities between otherwise different parts ofour programs. These similarities give us a framework in which tounderstand new things. Once you get used to the framework, it helpswith the understanding.

One way to think of a monad m is to see it as a workshop inwhich we can create and work with objects of type m a .

All monadic workshops m have a (>>) function. Itsgeneral type is

and it is often called a combinator. The type signaturefor (>>) particularizes to

in the IO monad.

I use the term object for anything a Haskell program canmanipulate. This includes functions. Objects whose type is ofthe form m a where m is a monad I will call monadicobjects.

Although the syntax requirements for (>>) are the same in all workshops, thebehavior of (>>) differs. One way to think of this would beto imagine that each workshop exists in its own universe with itsown physical laws. This of course would imply that the (>>) you see in one workshop wouldn't necessarily behave the same as inanother. It does not imply that the physical laws within any oneworkshop are completely arbitrary. As you read on, you will seethat the similarities between one monad and another go deeperthan mere syntax.

Each workshop has its own tools for manipulating its objects. The (>>) combinator is only one of four that must be present inall workshops.

Question What will the following program do?

Answer The function main will write the following on the console

and so on until the user stops it with ctl-c .

We have seen two functions, putStrLn and (>>) , belonging to the IO monad. Of these,only (>>) is required of all monads. Both putStrLn and its coworker getLine help give the IO monadits unique capabilities. This section introduces a second functionrequired of all monads and also provides a rather concrete explanation ofthe parameter a in IO a .

Suppose we want to echo user input. We would want to use the getLine function which obtains a line of user input from theconsole. But we cannot write

because the type signatures don't match; getLine produces an IO String and putStrLn requires a String . The typesignatures don't match because of Haskell's way of dealing with thepotential impurity of getLine . Haskell has getLine returna monadic object instead of a string.

Because getLine represents a monadic object it is opaque. That means the string it obtains cannot beseen. The potential impurity of getLine is squashed.The string that getLine obtains is stillthere but unavailable in any context that would violate referentialtransparency. Said bluntly, code that invokes getLine cannot tellthe difference between different evaluations of getLine .

This situation is something like riding a bicycle and having a carturn left immediately in front of you. Your immediate concern isavoiding the car. If the car hits you, the police will be concernedwith finding the driver. When you deal with a monadic object, it is similarly opaque.But there are ways itsdoor can be opened and then you are dealing withsomething on the interior rather than the object as a whole.

I will call the string obtained by an execution of getLine an