The Gentle Introduction To Haskell
back next
The I/O system in Haskell is purely functional, yet has all of the expressive power found in conventional programming languages. In imperative languages, programs proceed via actions which examine and modify the current state of the world. Typical actions include reading and setting global variables, writing files, reading input, and opening windows. Such actions are also a part of Haskell but are cleanly separated from the purely functional core of the language.
Haskell's I/O system is built around a somewhat daunting mathematical foundation: the monad. However, understanding of the underlying monad theory is not necessary to program using the I/O system. Rather, monads are a conceptual structure into which I/O happens to fit. It is no more necessary to understand monad theory to perform Haskell I/O than it is to understand group theory to do simple arithmetic.
The monadic operators that the I/O system is built upon are also used for other purposes; we will look more deeply into monads later. For now, we will avoid the term monad and concentrate on the use of the I/O system. It's best to think of the I/O monad as simply an abstract datatype.
Actions are defined rather than invoked within the expression evaluation engine that drives the execution of a Haskell program. Evaluating the definition of an action doesn't actually cause the action to happen. Rather, the invocation of actions takes place outside of the expression evaluation we have considered up to this point.
Actions are either atomic, as defined in system primitives, or are a sequential composition of other actions. The I/O monad contains primitives which build composite actions, a process is similar to joining statements in sequential order using `;' in other languages. This the monad serves as the glue which binds together the actions in a program.
Every action returns a value. In the type system, the return value is
`tagged' with IO type. This distinguishes actions from other
values. For example, the type
of the function getChar is:
getChar :: IO Char
The IO Char indicates that getChar, when invoked, performs
some action which returns a character. Actions which return no
interesting values use the unit type, (). For example, the
putChar function:
putChar :: Char -> IO ()
takes a character as an argument but returns nothing useful.
The unit type is similar to void in other languages.
Actions are sequenced using an operator that has a rather cryptic name: >>= (or `bind'). Instead of using this operator directly, we choose some syntactic sugar, the do notation, to hide these sequencing operators under a syntax resembling more conventional languages. The do notation can be trivially expanded to ordinary Haskell functions, as described in §3.14.
The keyword do introduces a sequence of statements
which are executed in order. A statement is either an action,
a pattern bound to the result of an action using <-, or
local definitions using let. The do notation
uses layout in the same manner as let or where so we
can omit braces and semicolons with proper indentation. Here is a
simple program to read and then print a character:
main = do c <- getc
putc c
The use of the name main is important: main
is defined to be the entry point of a Haskell program (similar
to the main function in C), and
must have the type IO (). (The name main is special only in the
module Main; we will have more to say about modules later.) This
program performs two actions in
sequence: first it reads in a character, binding the result to the
variable c, and then prints the character. Unlike a let expression
where variables are scoped over all definitions, the
variables defined by <- are only in scope in the following statements.
The patterns on the left of <- must be failure-free when doing I/O. Types with more than one constructor cannot be used in these patterns unless they are made irrefutable with a ~. See (§3.14) for more details. A static typing error occurs when a pattern is not failure-free.
There is still one missing piece. We can invoke actions and examine
their results using do, but how do we return a value from a sequence
of actions? For example, consider the ready function that reads a
character and returns True if the character was a `y':
ready :: IO Bool
ready = do c <- getChar
c == 'y'
This doesn't work because the second statement in the `do' is just a
boolean value, not an action. We need to take this boolean and create
an action that returns the boolean as it's result. The return
function does just that:
return :: a -> IO a
The return function completes the set of sequencing primitives. We
are now ready to look at more complicated I/O functions. First,
the function getLine:
getLine :: IO String
getLine = do c <- getChar
if c == '\n'
then return ""
else do l <- getLine
return (c:l)
Note the second do in the else clause. Each do introduces a single
chain of statements. Any intervening
construct, such as the if, must use a new do to initiate further
sequences of actions.
The return function admits a value to the realm of I/O actions.
What about the other direction? Can we invoke some I/O actions within an
ordinary expression? For example, how can we say x + print y
in an expression so that y is printed out as the
expression evaluates? The answer is we can't! It is not possible to
sneak into the imperative universe while in the midst of purely
functional code. Any value `infected' by the imperative world must be
tagged as such. A function such as
f :: Int -> Int -> Int
absolutely cannot do any I/O since IO does not
appear in the returned type.
This fact is often quite distressing to
programmers used to placing print statements liberally throughout
their code during debugging. There are, in fact, some rather
dangerous functions available to get around this problem but these are
better left to advanced programmers. Debugging packages often make
liberal use of these `forbidden functions' in an entirely safe
manner.
This sequencing behavior can be
found in other functions in the I/O system:
putStr :: String -> IO ()
putStr s = sequence (map putChar s)
One of the differences between Haskell and conventional
imperative programming can be seen in putStr. In an imperative
language, mapping an imperative version of putChar over the string
would be sufficient to print it. In Haskell, however, the map
function does not perform any action. Instead it creates a list of
actions, one for each character in the string. The folding operation
in sequence
uses the >> function to combine all of the individual actions into a
single action. The return () used here is
quite necessary -- foldr needs a null action at the end of the chain
of actions it creates (especially if there are no characters in the
string!).
The Prelude and the libraries contains many functions which are useful for sequencing I/O actions. These are usually generalized to arbitrary monads; any function with a context including Monad m => works with the IO type.
So far, we have avoided the issue of exceptions during I/O operations. What would happen if getChar encounters an end of file? (We use the term error for _|_: a condition which cannot be recovered from such as non-termination or pattern match failure. Exceptions, on the other hand, can be caught and handled within the I/O monad.) To deal with exceptional conditions such as `file not found' within the I/O monad, a handling mechanism is used, similar in functionality to the one in standard ML. No special syntax or semantics are used; exception handling is part of the definition of the I/O sequencing operations.
Errors are encoded using a special data type, IOError. This type
represents all possible exceptions that may occur within the I/O monad.
This is an abstract type: no constructors for IOError are available
to the user. Predicates allow IOError values to be
queried. For example, the function
isEOFError :: IOError -> Bool
determines whether an error was caused by an end-of-file condition.
By making IOError abstract, new sorts of errors may be added to the
system without a noticeable change to the datatype.
An exception handler has type IOError -> IO a.
The catch function associates an exception handler with an action or
set of actions:
catch :: IO a -> (IOError -> IO a) -> IO a
The arguments to catch are an action and a handler. If the action
succeeds, its result is returned without invoking the handler. If an
error occurs, it is passed to the handler as a value of type
IOError and the action associated with the handler is then invoked.
For example, this version of getChar returns a newline when an error
is encountered:
getChar' :: IO Char
getChar' = getChar `catch` (\e -> return '\n')
This is rather crude since it treats all errors in the same manner. If
only end-of-file is to be recognized, the error value must be queried:
getChar' :: IO Char
getChar' = getChar `catch` eofHandler where
eofHandler e = if isEofError e then return '\n' else fail e
The fail function used here passes an exception back to the next
exception handler. The type of fail is
fail :: IOError -> IO a
It is similar to
return except that it transfers control to the exception handler
instead of proceeding to the next
I/O action. Nested calls to catch are
permitted, and produce nested exception handlers.
Using getChar', we can redefine getLine to demonstrate the use of
nested handlers:
getLine' :: IO String
getLine' = catch getLine'' (\err -> "Error: " ++ show err) where
getLine'' = do c <- getChar'
if c == '\n' then return ""
else do l <- getLine'
return (c:l)
The nested error handlers allow getChar' to catch end of file while any other error results in a string starting with "Error: " from getLine'.
For convenience, Haskell provides a default exception handler at the topmost level of a program that prints out the exception and terminates the program.
Aside from the I/O monad and the exception handling mechanism it provides, I/O facilities in Haskell are for the most part quite similar to those in other languages. Many of these functions are in the IO library instead of the Prelude and thus must be explicitly imported to be in scope (modules and importing are discussed in Section 10). Also, many of these functions are discussed in the Library Report instead of the main report.
Opening a file creates a handle (of type Handle) for use in I/O
transactions. Closing the handle closes the associated file:
type FilePath = String -- path names in the file system
openFile :: FilePath -> IOMode -> IO Handle
hClose :: Handle -> IO ()
data IOMode = ReadMode | WriteMode | AppendMode | ReadWriteMode
Handles can also be associated with channels: communication ports
not directly attached to files. A few channel handles are predefined,
including stdin (standard input), stdout (standard output), and
stderr (standard error). Character level I/O operations include
hGetChar and hPutChar, which take a handle as an argument. The
getChar function used previously can be defined as:
getChar = hGetChar stdin
Haskell also allows the entire contents of a file or channel to be
returned as a single string:
getContents :: Handle -> String
Pragmatically, it may seem that getContents must immediately read an
entire file or channel, resulting in poor space and time performance
under certain conditions. However, this is not the case. The key
point is that getContents returns a "lazy" (i.e. non-strict) list
of characters (recall that strings are just lists of characters in
Haskell), whose elements are read "by demand" just like any other
list. An implementation can be expected to implement this
demand-driven behavior by reading one character at a time from the
file as they are required by the computation.
In this example, a Haskell program copies one file to another:
main = do fromHandle <- getAndOpenFile "Copy from: " ReadMode
toHandle <- getAndOpenFile "Copy to: " WriteMode
contents <- getContents fromHandle
hPutStr toHandle contents
close toHandle
putStr "Done."
getAndOpenFile :: String -> IOMode -> IO Handle
getAndOpenFile prompt mode =
do putStr prompt
name <- getLine
catch (\_ -> do putStr "Cannot open "++ name ++ "\n"
getAndOpenFile prompt mode)
openFile mode name
By using the lazy getContents function, the entire contents of the
file need not be read into memory all at once. If hPutStr chooses
to buffer the output by writing the string in fixed sized blocks of
characters, only one block of the input file needs to be in memory at
once. The input file is closed implicitly when the last character has
been read.
As a final note, I/O programming raises an important issue: this
style looks suspiciously like ordinary imperative programming. For
example, the getLine function:
getLine = do c <- getChar
if c == '\n'
then return ""
else do l <- getLine
return (c:l)
bears a striking similarity to imperative code (not in any real language) :
function getLine() {
c := getChar();
if c == `\n` then return ""
else {l := getLine();
return c:l}}
So, in the end, has Haskell simply re-invented the imperative wheel?
In some sense, yes. The I/O monad constitutes a small imperative sub-language inside Haskell, and thus the I/O component of a program may appear similar to ordinary imperative code. But there is one important difference: There is no special semantics that the user needs to deal with. In particular, equational reasoning in Haskell is not compromised. The imperative feel of the monadic code in a program does not detract from the functional aspect of Haskell. An experienced functional programmer should be able to minimize the imperative component of the program, only using the I/O monad for a minimal amount of top-level sequencing. The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds.