As you should have picked up by now, Haskell is a functional and lazy language. This has some dire consequences for something apparently simple like input/output, but we can solve this with the
The Problem: Input/Output and Purity
Haskell functions are in general pure functions: when given the same arguments, they return the same results. The reason for this paradigm is that pure functions are much easier to debug and to prove correct. Test cases can also be set up much more easily, since we can be sure that nothing other than the arguments will influence a function's result. We also require pure functions not to have side effects other than returning a value: a pure function must be self-contained, and cannot open a network connection, write a file or do anything other than producing its result. This allows the Haskell compiler to optimise the code very aggressively.
However, there are very useful functions that cannot be pure: an input function, say
getLine, will return different results every time it is called; indeed, that's the point of an input function, since an input function returning always the same result would be pointless. Output operations have side effects, such as creating files or printing strings on the terminal: this is also a violation of purity, because the function is no longer self-contained.
Unwilling to drop the purity of standard functions, but unable to do without impure ones, Haskell places the latter ones in the
IO monad. In other words, what we up to now have called "IO actions" are just values in the
IO monad is built in such a way as to be "closed", that is, it is not possible to make a
String out of a
IO String. Such an extraction would be possible for other monads, such as
Maybe String or
[String], but not for
IO String. In this way, any operation involving an impure function will be "tainted" with the
IO monad, which then functions as a signal: if the
IO monad is present in a function's signature, we know that that function may have side effects or may produce different results with the same inputs.
Another advantage of using monads is that, by concatenating I/O operations with the
(>>) operators, we provide an order in which these I/O operations will be executed. This is important because Haskell is a lazy language, and can decide to evaluate functions whenever the compiler decides it is appropriate: however, this can work only for pure functions! If an operation with side effects (say, writing a log file) were to be written lazily, its entries could be in just about any order: clearly not the result we desire. Locking I/O operations inside a monad allows to define a clear operating sequence.
Combining Pure Functions and Input/Output
If all useful operations entail input/output, why do we bother with pure functions? The reason is that, thanks to monad properties, we can still have pure functions doing the heavy work, and benefit from the ease with which they can be debugged, tested, proved correct and optimised, while we use the
IO monad to get our data and deliver our results.
Let's try a simple example: suppose we have a function converting a string to upper case:
> let shout = map Data.Char.toUpper
The type of this function is clearly pure:
> :t shout shout :: [Char] -> [Char]
Suppose you apply this function to a string with many repeated characters, for example:
> shout "aaaaaaaaaaaaagh!" "AAAAAAAAAAAAAGH!"
The Haskell compiler needs to apply the function only four times: for 'a', 'g', 'h' and '!'. A C compiler or a Perl interpreter, knowing nothing about purity or self-containment, would have to call the function for all 16 characters, since they cannot be sure that the function will not change its output somehow. The
shout function is really trivial, but remember that this line of reasoning is valid for any pure function, and this optimisation capability will be extremely valuable for more complex operations: suppose, for instance, that you had a function to render a character in a particular font, which is a much more expensive operation.
shout with I/O, we ask the user to insert a string (side effect: we are writing to screen), we read it (impure: result can be different every time), apply the (pure) function with
liftM and, finally, write the resulting string (again, side effect).
> putStr "Write your string: " >> liftM shout getLine >>= putStrLn Write your string: This is my string! THIS IS MY STRING!
donotation is especially popular with the
IOmonad, since it is not possible to extract values from it, and at the same time it is very convenient to use statements with
<-to store input values that have to be used multiple times after having been acquired. The above example could be written in
do putStr "Write your string: " string <- getLine putStrLn (shout string)
- Every Haskell program starts from the
mainfunction, which has type
IO (). Therefore, in reality, every line of Haskell code you have ever run has run in conjunction with the
- A way of viewing the
IOmonad is thinking of an
IO avalue as a computation which gives a value of type
awhile changing the state of the world by doing input and output. This state of the world is hidden from you by the
IOmonad, and obviously you cannot set it. Seen this way,
IOis roughly analogous to the
Statemonad, which we will meet shortly. With
State, however, the state being changed is made of normal Haskell values, and so we can manipulate it directly with pure functions.
- Actually, there is a "back door" out of the
System.IO.Unsafe.unsafePerformIO, which will transform, say, a
IO Stringinto a
String. The naming of the function should point out clearly enough that it is usually not a good idea to use it.
- Naturally, the standard library has many useful functions for performing I/O, all of them involving the
IOmonad. Several important ones are presented in the IO chapter in Haskell in Practice.
Monadic control structures
Given that monads allow us to express sequential execution of actions in a wholly general way, we would hope to use them to implement common iterative patterns, such as loops, in an elegant manner. In this section, we will present a few of the functions from the standard libraries which allow us to do precisely that. While the examples are being presented amidst a discussion on
IO for more immediate appeal, keep in mind that what we demonstrate here applies to every monad.
We begin by emphasizing that there is nothing magical about monadic values; we can manipulate them just like any other values in Haskell. Knowing that, we might try to, for instance, use the following to get five lines of user input:
fiveGetLines = replicate 5 getLine
That won't do, however (try it in GHCi!). The problem is that
replicate produces, in this case, a list of actions, while we want an action which returns a list (that is,
IO [String] rather than
[IO String]). What we need is a fold which runs down the list of actions, executing them and combining the results into a single list. As it happens, there is a Prelude function which does that:
sequence :: (Monad m) => [m a] -> m [a]
And so, we get the desired action.
fiveGetLines = sequence $ replicate 5 getLine
sequence form an appealing combination; and so Control.Monad offers a
replicateM function for repeating an action an arbitrary number of times.
Control.Monad provides a number of other convenience functions in the same spirit - monadic zips, folds, and so forth.
fiveGetLinesAlt = replicateM 5 getLine
A particularly important combination is that of
sequence; it allows us to make actions from a list of values, run them sequentially and collect the results.
mapM, a Prelude function, captures this pattern:
mapM :: (Monad m) => (a -> m b) -> [a] -> m [b]
Also common are the variants of the above functions with a trailing underscore in the name, such as
replicateM_. They discard the return values, and so are appropriate when you are only interested in the side effects (they are to their underscore-less counterparts what
(>>) is to
mapM_ for instance has the following type:
mapM_ :: (Monad m) => (a -> m b) -> [a] -> m ()
Finally, it is worth mentioning that
Control.Monad also provides
forM_, which are flipped versions of
forM_ happens to be the idiomatic Haskell counterpart to the imperative for-each loop; and the type signature suggests that neatly:
forM_ :: (Monad m) => [a] -> (a -> m b) -> m ()