We described IO a as “instructions (to the operating system) to produce a value of type a”, and showed how to build more complex instructions from simpler ones using do notation. Do notation does not only apply to IO, so much of what is described here is more general, but for now we will keep things concrete and talk about IO only.

The main problems that people have with Gen and IO is that they want to e.g. treat something of type IO String as if it had type String. This is wrong! You must learn to use do notation to create new instructions from old ones.

Example: using functions readFile and writeFile, write a function

backup :: FilePath -> IO()

which makes a backup of a given file with extension “.backup” added to the name.

Can you see what is wrong with this definition?:

-- Bad definition 
backup filename = writeFile (filename ++ ".backup") contents 
     where contents = readFile filename

contents has type IO String, but the definition is pretending that it is a String. FAIL!

We should use do-notation to combine these instructions into one:

-- good definition 
backup filename = do contents <- readFile filename 
                     writeFile (filename ++ ".backup") contents

Now contents does indeed have the type String and all is well.

Checklist for using do-notation:

The last line of a do block must have the same type as the whole do block. In the backup example the last line has type IO(), so that is the type of the whole do block.
lines before the last one have the form

pattern <- expression

or just

expression

where pattern is a pattern match for a value of some type a and the expression has type IO a.

In the example you can check that since readFile filename has type IO String then contents must have type String. Any variables in the pattern (contents is a variable) can be used in the rest of the do-block.

If you have a value v of type a but you need a value of type IO a , then you need to apply return. But do not apply return if your value already has type IO of something.

Example: instruction to read at most the first 80 characters of a file:


readFileSample :: FilePath -> IO String
readFileSample filename = do
     contents <- readFile filename
     return (take 80 contents)

Without the return the last line would have type String instead of IO String.

You can really fix a lot of problems if you think about types and the rules for do-blocks.

Exercises

1. Explain the error in each of these definitions

readFileSample1 filename = do 
  contents = readFile filename
  return (take 80 contents)

readFileSample2 filename = do 
    return (take 80 (readFile filename))

readFileInteractive :: IO String
readFileInteractive = do 
  putStrLn "Type a filename"
  filename <- getLine
  return (readFile filename)

2. Suppose you have the following functions:

readAllFiles :: IO [(FilePath,String)] 
zipFiles     :: [(FilePath,String)] -> String

readAllFiles is an instruction to produce a list of all the files in the current directory together with their contents. zipFiles is a function that takes such a list and “zips” it (i.e. compresses it) into a single string.

Using these, write an instruction backupDirectory :: IO () which creates a backup of the contents of a whole directory in a file called “backup.zip”

3. Write an instruction kidInCar :: IO () which repeatedly asks the user “Are we there yet?”, reads the reply, and only stops asking when the answer is “yes”. (Use standard functions putStrLn and getLine).

4. Define a function sumAll :: IO Int which reads positive integers from the input until a zero or a non-number is input, at which point it returns the sum of all the numbers input so far. A possible interaction might look like this:

ghci> sumAll
 Next number (anything else to quit): 2
  Next number (anything else to quit): 3
  Next number (anything else to quit): 100
  Next number (anything else to quit): done
105
ghci>

5. Anything which uses readFile may fail. Having a program crash is not a useful way to fail. Fortunately when working in IO there are ways to catch these failures.

For more "realistic" programming one should use

tryIOError :: IO a -> IO (Either IOError a)

from standard module System.IO.Error Using tryIOError (readFile ...), we turn an IO instruction that possibly generates an error into an IO instruction that never generates any error, but instead returns a value that tells us whether or not there was an error. Look at the documentation for the datatypes Either and IOError for more information and reimplement some examples which use readFile so that they do not crash on error.

6. Implement readAllFiles from question 2 using functions from the System.Directory library. Use tryIOError to catch possible errors from reading files.

7. Generalise the sumAll function from question 4 to a higher-order function

whileIO :: IO a -> (a -> Bool) -> (a -> a -> a) -> a -> IO a

and show how sumAll can be defined using whileIO.