Input and Output

We just defined a name called main and in it we call a function called
putStrLn with the parameter "hello, world". Looks pretty much run of the
mill, but it isn't, as we'll see in just a few moments. Save that file
as helloworld.hs.

And now, we're going to do something we've never done before. We're
actually going to compile our program! I'm so excited! Open up your
terminal and navigate to the directory where helloworld.hs is located
and do the following:

~~~~ {.plain name="code"}
$ ghc --make helloworld
[1 of 1] Compiling Main             ( helloworld.hs, helloworld.o )
Linking helloworld ...

And there we go, our first compiled program that printed out something
to the terminal. How extraordinarily boring!

Let's examine what we wrote. First, let's look at the type of the
function putStrLn.

~~~~ {.haskell:hs name="code"}
ghci> :t putStrLn
putStrLn :: String -> IO ()
ghci> :t putStrLn "hello, world"
putStrLn "hello, world" :: IO ()

Ah, interesting, new syntax! And this reads pretty much like an
imperative program. If you compile it and try it out, it will probably
behave just like you expect it to. Notice that we said *do* and then we
laid out a series of steps, like we would in an imperative program. Each
of these steps is an I/O action. By putting them together with *do*
syntax, we glued them into one I/O action. The action that we got has a
type of IO (), because that's the type of the last I/O action inside.

Because of that, main always has a type signature of main :: IO
*something*, where *something* is some concrete type. By convention, we
don't usually specify a type declaration for main.

An interesting thing that we haven't met before is the third line, which
states name \<- getLine. It looks like it reads a line from the input
and stores it into a variable called name. Does it really? Well, let's
examine the type of getLine.

~~~~ {.haskell:hs name="code"}
ghci> :t getLine
getLine :: IO String

and tellFortune (or any of the functions it passes name to) doesn't have
to know anything about I/O, it's just a normal String -\> String
function!

Take a look at this piece of code. Is it valid?

~~~~ {.haskell:hs name="code"}
nameTag = "Hello, my name is " ++ getLine

However, foo would just have a value of (), so doing that would be kind
of moot. Notice that we didn't bind the last putStrLn to anything.
That's because in a *do* block, *the last action cannot be bound to a
name* like the first two were. We'll see exactly why that is so a bit
later when we venture off into the world of monads. For now, you can
think of it in the way that the *do* block automatically extracts the
value from the last action and binds it to its own result.

Except for the last line, every line in a *do* block that doesn't bind
can also be written with a bind. So putStrLn "BLAH" can be written as \_
\<- putStrLn "BLAH". But that's useless, so we leave out the \<- for I/O
actions that don't contain an important result, like putStrLn
*something*.

Beginners sometimes think that doing

~~~~ {.haskell:hs name="code"}
name = getLine

Even when we just punch out a number or call a function in GHCI and
press return, it will evaluate it (as much as it needs) and then call
show on it and then it will print that string to the terminal using
putStrLn implicitly.

Remember *let* bindings? If you don't, refresh your memory on them by
reading [this section](syntax-in-functions#let-it-be). They have to be
in the form of let *bindings* in *expression*, where *bindings* are
names to be given to expressions and *expression* is the expression that
is to be evaluated that sees them. We also said that in list
comprehensions, the *in* part isn't needed. Well, you can use them in
*do* blocks pretty much like you use them in list comprehensions. Check
this out:

~~~~ {.haskell:hs name="code"}
import Data.Char

main = do
    putStrLn "What's your first name?"
    firstName <- getLine
    putStrLn "What's your last name?"
    lastName <- getLine
    let bigFirstName = map toUpper firstName
        bigLastName = map toUpper lastName
    putStrLn $ "hey " ++ bigFirstName ++ " " ++ bigLastName ++ ", how are you?"

To get a feel of what it does, you can run it before we go over the
code.

*Protip*: To run a program you can either compile it and then run the
produced executable file by doing ghc --make helloworld and then
./helloworld or you can use the runhaskell command like so: runhaskell
helloworld.hs and your program will be executed on the fly.

First, let's take a look at the reverseWords function. It's just a
normal function that takes a string like "hey there man" and then calls
words with it to produce a list of words like ["hey","there","man"].
Then we map reverse on the list, getting ["yeh","ereht","nam"] and then
we put that back into one string by using unwords and the final result
is "yeh ereht nam". See how we used function composition here. Without
function composition, we'd have to write something like reverseWords st
= unwords (map reverse (words st)).

What about main? First, we get a line from the terminal by performing
getLine call that line line. And now, we have a conditional expression.
Remember that in Haskell, every *if* must have a corresponding *else*
because every expression has to have some sort of value. We make the
*if* so that when a condition is true (in our case, the line that we
entered is blank), we perform one I/O action and when it isn't, the I/O
action under the *else* is performed. That's why in an I/O *do* block,
*if*s have to have a form of if *condition* then *I/O action* else *I/O
action*.

Let's first take a look at what happens under the *else* clause.
Because, we have to have exactly one I/O action after the *else*, we use
a *do* block to glue together two I/O actions into one. You could also
write that part out as:

~~~~ {.haskell:hs name="code"}
        else (do
            putStrLn $ reverseWords line
            main)

All these returns do is that they make I/O actions that don't really do
anything except have an encapsulated result and that result is thrown
away because it isn't bound to a name. We can use return in combination
with \<- to bind stuff to names.

~~~~ {.haskell:hs name="code"}
main = do
    a <- return "hell"
    b <- return "yeah!"
    putStrLn $ a ++ " " ++ b

When dealing with I/O *do* blocks, we mostly use return either because
we need to create an I/O action that doesn't do anything or because we
don't want the I/O action that's made up from a *do* block to have the
result value of its last action, but we want it to have a different
result value, so we use return to make an I/O action that always has our
desired result contained and we put it at the end.

A *do* block can also have just one I/O action. In that case, it's the
same as just writing the I/O action. Some people would prefer writing
then do return () in this case because the *else* also has a *do*.

Before we move on to files, let's take a look at some functions that are
useful when dealing with I/O.

putStr is much like putStrLn in that it takes a string as a parameter
and returns an I/O action that will print that string to the terminal,
only putStr doesn't jump into a new line after printing out the string
while putStrLn does.

~~~~ {.haskell:hs name="code"}
main = do   putStr "Hey, "
            putStr "I'm "
            putStrLn "Andy!"

Its type signature is putStr :: String -\> IO (), so the result
encapsulated within the resulting I/O action is the unit. A dud value,
so it doesn't make sense to bind it.

putChar takes a character and returns an I/O action that will print it
out to the terminal.

~~~~ {.haskell:hs name="code"}
main = do   putChar 't'
            putChar 'e'
            putChar 'h'

putStr is actually defined recursively with the help of putChar. The
edge condition of putStr is the empty string, so if we're printing an
empty string, just return an I/O action that does nothing by using
return (). If it's not empty, then print the first character of the
string by doing putChar and then print of them using putStr.

~~~~ {.haskell:hs name="code"}
putStr :: String -> IO ()
putStr [] = return ()
putStr (x:xs) = do
    putChar x
    putStr xs

~~~~ {.haskell:hs name="code"}
$ runhaskell print_test.hs
True
2
"haha"
3.2
[3,4,3]

When we want to print out strings, we usually use putStrLn because we
don't want the quotes around them, but for printing out values of other
types to the terminal, print is used the most.

getChar is an I/O action that reads a character from the input. Thus,
its type signature is getChar :: IO Char, because the result contained
within the I/O action is a Char. Note that due to buffering, reading of
the characters won't actually happen until the user mashes the return
key.

~~~~ {.haskell:hs name="code"}
main = do
    c <- getChar
    if c /= ' '
        then do
            putChar c
            main
        else return ()

The second line is the input. We input hello sir and then press return.
Due to buffering, the execution of the program will begin only when
after we've hit return and not after every inputted character. But once
we press return, it acts on what we've been putting in so far. Try
playing with this program to get a feel for it!

The when function is found in Control.Monad (to get access to it, do
import Control.Monad). It's interesting because in a *do* block it looks
like a control flow statement, but it's actually a normal function. It
takes a boolean value and an I/O action if that boolean value is True,
it returns the same I/O action that we supplied to it. However, if it's
False, it returns the return (), action, so an I/O action that doesn't
do anything. Here's how we could rewrite the previous piece of code with
which we demonstrated getChar by using when:

~~~~ {.haskell:hs name="code"}
import Control.Monad

main = do
    c <- getChar
    when (c /= ' ') $ do
        putChar c
        main

Is exactly the same as doing this:.

~~~~ {.haskell:hs name="code"}
main = do
    rs <- sequence [getLine, getLine, getLine]
    print rs

What's with the [(),(),(),(),()] at the end? Well, when we evaluate an
I/O action in GHCI, it's performed and then its result is printed out,
unless that result is (), in which case it's not printed out. That's why
evaluating putStrLn "hehe" in GHCI just prints out hehe (because the
contained result in putStrLn "hehe" is ()). But when we do getLine in
GHCI, the result of that I/O action is printed out, because getLine has
a type of IO String.

Because mapping a function that returns an I/O action over a list and
then sequencing it is so common, the utility functions mapM and mapM\_
were introduced. mapM takes a function and a list, maps the function
over the list and then sequences it. mapM\_ does the same, only it
throws away the result later. We usually use mapM\_ when we don't care
what result our sequenced I/O actions have.

~~~~ {.haskell:hs name="code"}
ghci> mapM print [1,2,3]
1
2
3
[(),(),()]
ghci> mapM_ print [1,2,3]
1
2
3

forM (located in Control.Monad) is like mapM, only that it has its
parameters switched around. The first parameter is the list and the
second one is the function to map over that list, which is then
sequenced. Why is that useful? Well, with some creative use of lambdas
and *do* notation, we can do stuff like this:

~~~~ {.haskell:hs name="code"}
import Control.Monad

main = do
    colors <- forM [1,2,3,4] (\a -> do
        putStrLn $ "Which color do you associate with the number " ++ show a ++ "?"
        color <- getLine
        return color)
    putStrLn "The colors that you associate with 1, 2, 3 and 4 are: "
    mapM putStrLn colors

We could have actually done that without forM, only with forM it's more
readable. Normally we write forM when we want to map and sequence some
actions that we define there on the spot using *do* notation. In the
same vein, we could have replaced the last line with forM colors
putStrLn.

In this section, we learned the basics of input and output. We also
found out what I/O actions are, how they enable us to do input and
output and when they are actually performed. To reiterate, I/O actions
are values much like any other value in Haskell. We can pass them as
parameters to functions and functions can return I/O actions as results.
What's special about them is that if they fall into the main function
(or are the result in a GHCI line), they are performed. And that's when
they get to write stuff on your screen or play Yakety Sax through your
speakers. Each I/O action can also encapsulate a result with which it
tells you what it got from the real world.

Don't think of a function like putStrLn as a function that takes a
string and prints it to the screen. Think of it as a function that takes
a string and returns an I/O action. That I/O action will, when
performed, print beautiful poetry to your terminal.

Files and streams
-----------------

![streams](/pages/img/streams.png)

getChar is an I/O action that reads a single character from the
terminal. getLine is an I/O action that reads a line from the terminal.
These two are pretty straightforward and most programming languages have
some functions or statements that are parallel to them. But now, let's
meet getContents. getContents is an I/O action that reads everything
from the standard input until it encounters an end-of-file character.
Its type is getContents :: IO String. What's cool about getContents is
that it does lazy I/O. When we do foo \<- getContents, it doesn't read
all of the input at once, store it in memory and then bind it to foo.
No, it's lazy! It'll say: *"Yeah yeah, I'll read the input from the
terminal later as we go along, when you really need it!"*.

getContents is really useful when we're piping the output from one
program into the input of our program. In case you don't know how piping
works in unix-y systems, here's a quick primer. Let's make a text file
that contains the following little haiku:

~~~~ {.plain name="code"}
I'm a lil' teapot
What's with that airplane food, huh?
It's so small, tasteless

We'll save that program as capslocker.hs or something and compile it.
And then, we're going to use a unix pipe to feed our text file directly
to our little program. We're going to use the help of the GNU *cat*
program, which prints out a file that's given to it as an argument.
Check it out, booyaka!

~~~~ {.plain name="code"}
$ ghc --make capslocker
[1 of 1] Compiling Main             ( capslocker.hs, capslocker.o )
Linking capslocker ...
$ cat haiku.txt
I'm a lil' teapot
What's with that airplane food, huh?
It's so small, tasteless
$ cat haiku.txt | ./capslocker
I'M A LIL' TEAPOT
WHAT'S WITH THAT AIRPLANE FOOD, HUH?
IT'S SO SMALL, TASTELESS
capslocker <stdin>: hGetLine: end of file

We run the getContents I/O action and name the string it produces
contents. Then, we map toUpper over that string and print that to the
terminal. Keep in mind that because strings are basically lists, which
are lazy, and getContents is I/O lazy, it won't try to read the whole
content at once and store it into memory before printing out the
capslocked version. Rather, it will print out the capslocked version as
it reads it, because it will only read a line from the input when it
really needs to.

~~~~ {.plain name="code"}
$ cat haiku.txt | ./capslocker
I'M A LIL' TEAPOT
WHAT'S WITH THAT AIRPLANE FOOD, HUH?
IT'S SO SMALL, TASTELESS

We got out of that by pressing Ctrl-D. Pretty nice! As you can see, it
prints out our capslocked input back to us line by line. When the result
of getContents is bound to contents, it's not represented in memory as a
real string, but more like a promise that it will produce the string
eventually. When we map toUpper over contents, that's also a promise to
map that function over the eventual contents. And finally when putStr
happens, it says to the previous promise: *"Hey, I need a capslocked
line!"*. It doesn't have any lines yet, so it says to contents: *"Hey,
how about actually getting a line from the terminal?"*. So that's when
getContents actually reads from the terminal and gives a line to the
code that asked it to produce something tangible. That code then maps
toUpper over that line and gives it to putStr, which prints it. And
then, putStr says: *"Hey, I need the next line, come on!"* and this
repeats until there's no more input, which is signified by an
end-of-file character.

Let's make program that takes some input and prints out only those lines
that are shorter than 10 characters. Observe:

~~~~ {.haskell:hs name="code"}
main = do
    contents <- getContents
    putStr (shortLinesOnly contents)

shortLinesOnly :: String -> String
shortLinesOnly input =
    let allLines = lines input
        shortLines = filter (\line -> length line < 10) allLines
        result = unlines shortLines
    in  result

~~~~ {.plain:hs name="code"}
$ ghc --make shortlinesonly
[1 of 1] Compiling Main             ( shortlinesonly.hs, shortlinesonly.o )
Linking shortlinesonly ...
$ cat shortlines.txt | ./shortlinesonly
i'm short
so am i
short

Just to show that this can be achieved in much less code (even though it
will be less readable) and to demonstrate our function composition
skill, we're going to rework that a bit further.

~~~~ {.haskell:hs name="code"}
main = interact $ unlines . filter ((<10) . length) . lines

Let's write this in point-free.

~~~~ {.haskell:hs name="code"}
respondPalindromes = unlines . map (\xs -> if isPalindrome xs then "palindrome" else "not a palindrome") . lines
    where   isPalindrome xs = xs == reverse xs

Let's test this out:

~~~~ {.plain name="code"}
$ runhaskell palindromes.hs
hehe
not a palindrome
ABCBA
palindrome
cookie
not a palindrome

and we save it as words.txt. This is what we get by piping it into our
program:

~~~~ {.plain name="code"}
$ cat words.txt | runhaskell palindromes.hs
not a palindrome
palindrome
palindrome
palindrome

And here's our program:

~~~~ {.haskell:hs name="code"}
import System.IO

main = do
    handle <- openFile "girlfriend.txt" ReadMode
    contents <- hGetContents handle
    putStr contents
    hClose handle

Let's go over this line by line. The first line is just four
exclamations, to get our attention. In the second line, Avril tells us
that she doesn't like our current romantic partner. The third line
serves to emphasize that disapproval, whereas the fourth line suggests
we should seek out a new girlfriend.

Let's also go over the program line by line! Our program is several I/O
actions glued together with a *do* block. In the first line of the *do*
block, we notice a new function called openFile. This is its type
signature: openFile :: FilePath -\> IOMode -\> IO Handle. If you read
that out loud, it states: openFile takes a file path and an IOMode and
returns an I/O action that will open a file and have the file's
associated handle encapsulated as its result.

FilePath is just a [type
synonym](making-our-own-types-and-typeclasses#type-synonyms) for String,
simply defined as:

~~~~ {.haskell:hs name="code"}
type FilePath = String

![A FILE IN A CAKE!!!](/pages/img/file.png)

Just like our type that represents the seven possible values for the
days of the week, this type is an enumeration that represents what we
want to do with our opened file. Very simple. Just note that this type
is IOMode and not IO Mode. IO Mode would be the type of an I/O action
that has a value of some type Mode as its result, but IOMode is just a
simple enumeration.

Finally, it returns an I/O action that will open the specified file in
the specified mode. If we bind that action to something we get a Handle.
A value of type Handle represents where our file is. We'll use that
handle so we know which file to read from. It would be stupid to read a
file but not bind that read to a handle because we wouldn't be able to
do anything with the file. So in our case, we bound the handle to
handle.

In the next line, we see a function called hGetContents. It takes a
Handle, so it knows which file to get the contents from and returns an
IO String — an I/O action that holds as its result the contents of the
file. This function is pretty much like getContents. The only difference
is that getContents will automatically read from the standard input
(that is from the terminal), whereas hGetContents takes a file handle
which tells it which file to read from. In all other respects, they work
the same. And just like getContents, hGetContents won't attempt to read
the file at once and store it in memory, but it will read it as needed.
That's really cool because we can treat contents as the whole contents
of the file, but it's not really loaded in memory. So if this were a
really huge file, doing hGetContents wouldn't choke up our memory, but
it would read only what it needed to from the file, when it needed to.

Note the difference between the handle used to identify a file and the
contents of the file, bound in our program to handle and contents. The
handle is just something by which we know what our file is. If you
imagine your whole file system to be a really big book and each file is
a chapter in the book, the handle is a bookmark that shows where you're
currently reading (or writing) a chapter, whereas the contents are the
actual chapter.

With putStr contents we just print the contents out to the standard
output and then we do hClose, which takes a handle and returns an I/O
action that closes the file. You have to close the file yourself after
opening it with openFile!

Another way of doing what we just did is to use the withFile function,
which has a type signature of withFile :: FilePath -\> IOMode -\>
(Handle -\> IO a) -\> IO a. It takes a path to a file, an IOMode and
then it takes a function that takes a handle and returns some I/O
action. What it returns is an I/O action that will open that file, do
something we want with the file and then close it. The result
encapsulated in the final I/O action that's returned is the same as the
result of the I/O action that the function we give it returns. This
might sound a bit complicated, but it's really simple, especially with
lambdas, here's our previous example rewritten to use withFile:

~~~~ {.haskell:hs name="code"}
import System.IO

main = do
    withFile "girlfriend.txt" ReadMode (\handle -> do
        contents <- hGetContents handle
        putStr contents)

![butter toast](/pages/img/edd.png)

We know the result will be an I/O action so we can just start off with a
*do*. First we open the file and get a handle from it. Then, we apply
handle to our function to get back the I/O action that does all the
work. We bind that action to result, close the handle and then do return
result. By returning the result encapsulated in the I/O action that we
got from f, we make it so that our I/O action encapsulates the same
result as the one we got from f handle. So if f handle returns an action
that will read a number of lines from the standard input and write them
to a file and have as its result encapsulated the number of lines it
read, if we used that with withFile', the resulting I/O action would
also have as its result the number of lines read.

Just like we have hGetContents that works like getContents but for a
specific file, there's also hGetLine, hPutStr, hPutStrLn, hGetChar, etc.
They work just like their counterparts without the *h*, only they take a
handle as a parameter and operate on that specific file instead of
operating on standard input or standard output. Example: putStrLn is a
function that takes a string and returns an I/O action that will print
out that string to the terminal and a newline after it. hPutStrLn takes
a handle and a string and returns an I/O action that will write that
string to the file associated with the handle and then put a newline
after it. In the same vein, hGetLine takes a handle and returns an I/O
action that reads a line from its file.

Loading files and then treating their contents as strings is so common
that we have these three nice little functions to make our work even
easier:

readFile has a type signature of readFile :: FilePath -\> IO String.
Remember, FilePath is just a fancy name for String. readFile takes a
path to a file and returns an I/O action that will read that file
(lazily, of course) and bind its contents to something as a string. It's
usually more handy than doing openFile and binding it to a handle and
then doing hGetContents. Here's how we could have written our previous
example with readFile:

~~~~ {.haskell:hs name="code"}
import System.IO

main = do
    contents <- readFile "girlfriend.txt"
    putStr contents

~~~~ {.plain name="code"}
$ runhaskell girlfriendtocaps.hs
$ cat girlfriendcaps.txt
HEY! HEY! YOU! YOU!
I DON'T LIKE YOUR GIRLFRIEND!
NO WAY! NO WAY!
I THINK YOU NEED A NEW ONE!

~~~~ {.plain name="code"}
$ runhaskell appendtodo.hs
Iron the dishes
$ runhaskell appendtodo.hs
Dust the dog
$ runhaskell appendtodo.hs
Take salad out of the oven
$ cat todo.txt
Iron the dishes
Dust the dog
Take salad out of the oven

is actually like connecting a pipe from the file to the output. Just
like you can think of lists as streams, you can also think of files as
streams. This will read one line at a time and print it out to the
terminal as it goes along. So you may be asking, how wide is this pipe
then? How often will the disk be accessed? Well, for text files, the
default buffering is line-buffering usually. That means that the
smallest part of the file to be read at once is one line. That's why in
this case it actually reads a line, prints it to the output, reads the
next line, prints it, etc. For binary files, the default buffering is
usually block-buffering. That means that it will read the file chunk by
chunk. The chunk size is some size that your operating system thinks is
cool.

You can control how exactly buffering is done by using the hSetBuffering
function. It takes a handle and a BufferMode and returns an I/O action
that sets the buffering. BufferMode is a simple enumeration data type
and the possible values it can hold are: NoBuffering, LineBuffering or
BlockBuffering (Maybe Int). The Maybe Int is for how big the chunk
should be, in bytes. If it's Nothing, then the operating system
determines the chunk size. NoBuffering means that it will be read one
character at a time. NoBuffering usually sucks as a buffering mode
because it has to access the disk so much.

Here's our previous piece of code, only it doesn't read it line by line
but reads the whole file in chunks of 2048 bytes.

~~~~ {.haskell:hs name="code"}
main = do
    withFile "something.txt" ReadMode (\handle -> do
        hSetBuffering handle $ BlockBuffering (Just 2048)
        contents <- hGetContents handle
        putStr contents)

At first, we just open *todo.txt* in read mode and bind its handle to
handle.

Next up, we use a function that we haven't met before which is from
System.IO — openTempFile. Its name is pretty self-explanatory. It takes
a path to a temporary directory and a template name for a file and opens
a temporary file. We used "." for the temporary directory, because .
denotes the current directory on just about any OS. We used "temp" as
the template name for the temporary file, which means that the temporary
file will be named *temp* plus some random characters. It returns an I/O
action that makes the temporary file and the result in that I/O action
is a pair of values: the name of the temporary file and a handle. We
could just open a normal file called *todo2.txt* or something like that
but it's better practice to use openTempFile so you know you're probably
not overwriting anything.

The reason we didn't use getCurrentDirectory to get the current
directory and then pass it to openTempFile but instead just passed "."
to openTempFile is because . refers to the current directory on
unix-like system and Windows

Next up, we bind the contents of *todo.txt* to contents. Then, split
that string into a list of strings, each string one line. So todoTasks
is now something like ["Iron the dishes", "Dust the dog", "Take salad
out of the oven"]. We zip the numbers from 0 onwards and that list with
a function that takes a number, like 3, and a string, like "hey" and
returns "3 - hey", so numberedTasks is ["0 - Iron the dishes", "1 - Dust
the dog" .... We join that list of strings into a single newline
delimited string with unlines and print that string out to the terminal.
Note that instead of doing that, we could have also done mapM putStrLn
numberedTasks

We ask the user which one they want to delete and wait for them to enter
a number. Let's say they want to delete number 1, which is Dust the dog,
so they punch in 1. numberString is now "1" and because we want a
number, not a string, we run read on that to get 1 and bind that to
number.

Remember the delete and !! functions from Data.List. !! returns an
element from a list with some index and delete deletes the first
occurence of an element in a list and returns a new list without that
occurence. (todoTasks !! number) (number is now 1) returns "Dust the
dog". We bind todoTasks without the first occurence of "Dust the dog" to
newTodoItems and then join that into a single string with unlines before
writing it to the temporary file that we opened. The old file is now
unchanged and the temporary file contains all the lines that the old one
does, except the one we deleted.

After that we close both the original and the temporary files and then
we remove the original one with removeFile, which, as you can see, takes
a path to a file and deletes it. After deleting the old *todo.txt*, we
use renameFile to rename the temporary file to *todo.txt*. Be careful,
removeFile and renameFile (which are both in System.Directory by the
way) take file paths as their parameters, not handles.

And that's that! We could have done this in even fewer lines, but we
were very careful not to overwrite any existing files and politely asked
the operating system to tell us where we can put our temporary file.
Let's give this a go!

~~~~ {.plain name="code"}
$ runhaskell deletetodo.hs
These are your TO-DO items:
0 - Iron the dishes
1 - Dust the dog
2 - Take salad out of the oven
Which one do you want to delete?
1

$ cat todo.txt
Iron the dishes
Take salad out of the oven

$ runhaskell deletetodo.hs
These are your TO-DO items:
0 - Iron the dishes
1 - Take salad out of the oven
Which one do you want to delete?
0

$ cat todo.txt
Take salad out of the oven

We bind getArgs and progName to args and progName. We say The arguments
are: and then for every argument in args, we do putStrLn. Finally, we
also print out the program name. Let's compile this as arg-test.

~~~~ {.plain name="code"}
$ ./arg-test first second w00t "multi word arg"
The arguments are:
first
second
w00t
multi word arg
The program name is:
arg-test

We have yet to define main, add, view and remove, so let's start with
main:

~~~~ {.haskell:hs name="code"}
main = do
    (command:args) <- getArgs
    let (Just action) = lookup command dispatch
    action args

If we call our program like todo add todo.txt "Spank the monkey", the
"add" will get bound to command in the first pattern match in the main
block, whereas ["todo.txt", "Spank the monkey"] will get passed to the
function that we get from the dispatch list. So, because we're not
dealing with bad input right now, we just pattern match against a list
with those two elements right away and return an I/O action that appends
that line to the end of the file, along with a newline character.

Next, let's implement the list viewing functionality. If we want to view
the items in a file, we do todo view todo.txt. So in the first pattern
match, command will be "view" and args will be ["todo.txt"].

~~~~ {.haskell:hs name="code"}
view :: [String] -> IO ()
view [fileName] = do
    contents <- readFile fileName
    let todoTasks = lines contents
        numberedTasks = zipWith (\n line -> show n ++ " - " ++ line) [0..] todoTasks
    putStr $ unlines numberedTasks

We opened up the file based on fileName and opened a temporary file,
deleted the line with the index that the user wants to delete, wrote
that to the temporary file, removed the original file and renamed the
temporary file back to fileName.

Here's the whole program at once, in all its glory!

~~~~ {.haskell:hs name="code"}
import System.Environment
import System.Directory
import System.IO
import Data.List

dispatch :: [(String, [String] -> IO ())]
dispatch =  [ ("add", add)
            , ("view", view)
            , ("remove", remove)
            ]

main = do
    (command:args) <- getArgs
    let (Just action) = lookup command dispatch
    action args

add :: [String] -> IO ()
add [fileName, todoItem] = appendFile fileName (todoItem ++ "\n")

view :: [String] -> IO ()
view [fileName] = do
    contents <- readFile fileName
    let todoTasks = lines contents
        numberedTasks = zipWith (\n line -> show n ++ " - " ++ line) [0..] todoTasks
    putStr $ unlines numberedTasks

remove :: [String] -> IO ()
remove [fileName, numberString] = do
    handle <- openFile fileName ReadMode
    (tempName, tempHandle) <- openTempFile "." "temp"
    contents <- hGetContents handle
    let number = read numberString
        todoTasks = lines contents
        newTodoItems = delete (todoTasks !! number) todoTasks
    hPutStr tempHandle $ unlines newTodoItems
    hClose handle
    hClose tempHandle
    removeFile fileName
    renameFile tempName fileName

Another cool thing about this is that it's easy to add extra
functionality. Just add an entry in the dispatch association list and
implement the corresponding function and you're laughing! As an
exercise, you can try implementing a bump function that will take a file
and a task number and return an I/O action that bumps that task to the
top of the to-do list.

You could make this program fail a bit more gracefully in case of bad
input (for example, if someone runs todo UP YOURS HAHAHAHA) by making an
I/O action that just reports there has been an error (say, errorExit ::
IO ()) and then check for possible erronous input and if there is
erronous input, perform the error reporting I/O action. Another way is
to use exceptions, which we will meet soon.

Randomness
----------

![this picture is the ultimate source of randomness and
wackiness](img/random.png)

Many times while programming, you need to get some random data. Maybe
you're making a game where a die needs to be thrown or you need to
generate some test data to test out your program. There are a lot of
uses for random data when programming. Well, actually, pseudo-random,
because we all know that the only true source of randomness is a monkey
on a unicycle with a cheese in one hand and its butt in the other. In
this section, we'll take a look at how to make Haskell generate
seemingly random data.

In most other programming languages, you have functions that give you
back some random number. Each time you call that function, you get back
a (hopefully) different random number. How about Haskell? Well,
remember, Haskell is a pure functional language. What that means is that
it has referential transparency. What THAT means is that a function, if
given the same parameters twice, must produce the same result twice.
That's really cool because it allows us to reason differently about
programs and it enables us to defer evaluation until we really need it.
If I call a function, I can be sure that it won't do any funny stuff
before giving me the results. All that matters are its results. However,
this makes it a bit tricky for getting random numbers. If I have a
function like this:

~~~~ {.haskell:hs name="code"}
randomNumber :: (Num a) => a
randomNumber = 4

~~~~ {.plain name="code"}
<interactive>:1:0:
    Ambiguous type variable `a' in the constraint:
      `Random a' arising from a use of `random' at <interactive>:1:0-20
    Probable fix: add a type signature that fixes these type variable(s)

Finally! A number that looks kind of random! The first component of the
tuple is our number whereas the second component is a textual
representation of our new random generator. What happens if we call
random with the same random generator again?

~~~~ {.haskell:hs name="code"}
ghci> random (mkStdGen 100) :: (Int, StdGen)
(-1352021624,651872571 1655838864)

Alright, cool, great, a different number. We can use the type annotation
to get different types back from that function.

~~~~ {.haskell:hs name="code"}
ghci> random (mkStdGen 949488) :: (Float, StdGen)
(0.8938442,1597344447 1655838864)
ghci> random (mkStdGen 949488) :: (Bool, StdGen)
(False,1485632275 40692)
ghci> random (mkStdGen 949488) :: (Integer, StdGen)
(1691547873,1597344447 1655838864)

We call random with the generator we got as a parameter to get a coin
and a new generator. Then we call it again, only this time with our new
generator, to get the second coin. We do the same for the third coin.
Had we called it with the same generator every time, all the coins would
have had the same value and we'd only be able to get (False, False,
False) or (True, True, True) as a result.

~~~~ {.haskell:hs name="code"}
ghci> threeCoins (mkStdGen 21)
(True,True,True)
ghci> threeCoins (mkStdGen 22)
(True,False,True)
ghci> threeCoins (mkStdGen 943)
(True,False,True)
ghci> threeCoins (mkStdGen 944)
(True,True,True)

Why doesn't randoms return a new generator as well as a list? We could
implement the randoms function very easily like this:

~~~~ {.haskell:hs name="code"}
randoms' :: (RandomGen g, Random a) => g -> [a]
randoms' gen = let (value, newGen) = random gen in value:randoms' newGen

Again, a recursive definition. We say that if we want 0 numbers, we just
return an empty list and the generator that was given to us. For any
other number of random values, we first get one random number and a new
generator. That will be the head. Then we say that the tail will be *n -
1* numbers generated with the new generator. Then we return the head and
the rest of the list joined and the final generator that we got from
getting the *n - 1* random numbers.

What if we want a random value in some sort of range? All the random
integers so far were outrageously big or small. What if we want to to
throw a die? Well, we use randomR for that purpose. It has a type of
randomR :: (RandomGen g, Random a) :: (a, a) -\> g -\> (a, g), meaning
that it's kind of like random, only it takes as its first parameter a
pair of values that set the lower and upper bounds and the final value
produced will be within those bounds.

~~~~ {.haskell:hs name="code"}
ghci> randomR (1,6) (mkStdGen 359353)
(6,1494289578 40692)
ghci> randomR (1,6) (mkStdGen 35935335)
(3,1250031057 40692)

Nice, looks like a super secret password or something.

You may be asking yourself, what does this section have to do with I/O
anyway? We haven't done anything concerning I/O so far. Well, so far
we've always made our random number generator manually by making it with
some arbitrary integer. The problem is, if we do that in our real
programs, they will always return the same random numbers, which is no
good for us. That's why System.Random offers the getStdGen I/O action,
which has a type of IO StdGen. When your program starts, it asks the
system for a good random number generator and stores that in a so called
global generator. getStdGen fetches you that global random generator
when you bind it to something.

Here's a simple program that generates a random string.

~~~~ {.haskell:hs name="code"}
import System.Random

main = do
    gen <- getStdGen
    putStr $ take 20 (randomRs ('a','z') gen)

Be careful though, just performing getStdGen twice will ask the system
for the same global generator twice. If you do this:

~~~~ {.haskell:hs name="code"}
import System.Random

main = do
    gen <- getStdGen
    putStrLn $ take 20 (randomRs ('a','z') gen)
    gen2 <- getStdGen
    putStr $ take 20 (randomRs ('a','z') gen2)

Another way is to use the newStdGen action, which splits our current
random generator into two generators. It updates the global random
generator with one of them and encapsulates the other as its result.

~~~~ {.haskell:hs name="code"}
import System.Random

main = do
    gen <- getStdGen
    putStrLn $ take 20 (randomRs ('a','z') gen)
    gen' <- newStdGen
    putStr $ take 20 (randomRs ('a','z') gen')

![jack of diamonds](/pages/img/jackofdiamonds.png)

We make a function askForNumber, which takes a random number generator
and returns an I/O action that will prompt the user for a number and
tell him if he guessed it right. In that function, we first generate a
random number and a new generator based on the generator that we got as
a parameter and call them randNumber and newGen. Let's say that the
number generated was 7. Then we tell the user to guess which number
we're thinking of. We perform getLine and bind its result to
numberString. When the user enters 7, numberString becomes "7". Next, we
use when to check if the string the user entered is an empty string. If
it is, an empty I/O action of return () is performed, which effectively
ends the program. If it isn't, the action consisting of that *do* block
right there gets performed. We use read on numberString to convert it to
a number, so number is now 7.

**Excuse me!** If the user gives us some input here that read can't read
(like "haha"), our program will crash with an ugly error message. If you
don't want your program to crash on erronous input, use reads, which
returns an empty list when it fails to read a string. When it succeeds,
it returns a singleton list with a tuple that has our desired value as
one component and a string with what it didn't consume as the other.

We check if the number that we entered is equal to the one generated
randomly and give the user the appropriate message. And then we call
askForNumber recursively, only this time with the new generator that we
got, which gives us an I/O action that's just like the one we performed,
only it depends on a different generator and we perform it.

main consists of just getting a random generator from the system and
calling askForNumber with it to get the initial action.

Here's our program in action!

~~~~ {.plain name="code"}
$ runhaskell guess_the_number.hs
Which number in the range from 1 to 10 am I thinking of? 4
Sorry, it was 3
Which number in the range from 1 to 10 am I thinking of? 10
You are correct!
Which number in the range from 1 to 10 am I thinking of? 2
Sorry, it was 4
Which number in the range from 1 to 10 am I thinking of? 5
Sorry, it was 10
Which number in the range from 1 to 10 am I thinking of?

It's very similar to the previous version, only instead of making a
function that takes a generator and then calls itself recursively with
the new updated generator, we do all the work in main. After telling the
user whether they were correct in their guess or not, we update the
global generator and then call main again. Both approaches are valid but
I like the first one more since it does less stuff in main and also
provides us with a function that we can reuse easily.

Bytestrings
-----------

![like normal string, only they byte ... what a pedestrian pun this
is](img/chainchomp.png)

Lists are a cool and useful data structure. So far, we've used them
pretty much everywhere. There are a multitude of functions that operate
on them and Haskell's laziness allows us to exchange the for and while
loops of other languages for filtering and mapping over lists, because
evaluation will only happen once it really needs to, so things like
infinite lists (and even infinite lists of infinite lists!) are no
problem for us. That's why lists can also be used to represent streams,
either when reading from the standard input or when reading from files.
We can just open a file and read it as a string, even though it will
only be accessed when the need arises.

However, processing files as strings has one drawback: it tends to be
slow. As you know, String is a type synonym for [Char]. Chars don't have
a fixed size, because it takes several bytes to represent a character
from, say, Unicode. Furthemore, lists are really lazy. If you have a
list like [1,2,3,4], it will be evaluated only when completely
necessary. So the whole list is sort of a promise of a list. Remember
that [1,2,3,4] is syntactic sugar for 1:2:3:4:[]. When the first element
of the list is forcibly evaluated (say by printing it), the rest of the
list 2:3:4:[] is still just a promise of a list, and so on. So you can
think of lists as promises that the next element will be delivered once
it really has to and along with it, the promise of the element after it.
It doesn't take a big mental leap to conclude that processing a simple
list of numbers as a series of promises might not be the most efficient
thing in the world.

That overhead doesn't bother us so much most of the time, but it turns
out to be a liability when reading big files and manipulating them.
That's why Haskell has *bytestrings*. Bytestrings are sort of like
lists, only each element is one byte (or 8 bits) in size. The way they
handle laziness is also different.

Bytestrings come in two flavors: strict and lazy ones. Strict
bytestrings reside in Data.ByteString and they do away with the laziness
completely. There are no promises involved; a strict bytestring
represents a series of bytes in an array. You can't have things like
infinite strict bytestrings. If you evaluate the first byte of a strict
bytestring, you have to evaluate it whole. The upside is that there's
less overhead because there are no thunks (the technical term for
*promise*) involved. The downside is that they're likely to fill your
memory up faster because they're read into memory at once.

The other variety of bytestrings resides in Data.ByteString.Lazy.
They're lazy, but not quite as lazy as lists. Like we said before, there
are as many thunks in a list as there are elements. That's what makes
them kind of slow for some purposes. Lazy bytestrings take a different
approach — they are stored in chunks (not to be confused with thunks!),
each chunk has a size of 64K. So if you evaluate a byte in a lazy
bytestring (by printing it or something), the first 64K will be
evaluated. After that, it's just a promise for the rest of the chunks.
Lazy bytestrings are kind of like lists of strict bytestrings with a
size of 64K. When you process a file with lazy bytestrings, it will be
read chunk by chunk. This is cool because it won't cause the memory
usage to skyrocket and the 64K probably fits neatly into your CPU's L2
cache.

If you look through the
[documentation](http://www.haskell.org/ghc/docs/latest/html/libraries/bytestring/Data-ByteString-Lazy.html)
for Data.ByteString.Lazy, you'll see that it has a lot of functions that
have the same names as the ones from Data.List, only the type signatures
have ByteString instead of [a] and Word8 instead of a in them. The
functions with the same names mostly act the same as the ones that work
on lists. Because the names are the same, we're going to do a qualified
import in a script and then load that script into GHCI to play with
bytestrings.

~~~~ {.haskell:hs name="code"}
import qualified Data.ByteString.Lazy as B
import qualified Data.ByteString as S

As you can see, you usually don't have to worry about the Word8 too
much, because the type system can makes the numbers choose that type. If
you try to use a big number, like 336 as a Word8, it will just wrap
around to 80.

We packed only a handful of values into a ByteString, so they fit inside
one chunk. The Empty is like the [] for lists.

unpack is the inverse function of pack. It takes a bytestring and turns
it into a list of bytes.

fromChunks takes a list of strict bytestrings and converts it to a lazy
bytestring. toChunks takes a lazy bytestring and converts it to a list
of strict ones.

~~~~ {.haskell:hs name="code"}
ghci> B.fromChunks [S.pack [40,41,42], S.pack [43,44,45], S.pack [46,47,48]]
Chunk "()*" (Chunk "+,-" (Chunk "./0" Empty))

As you can see empty makes an empty bytestring. See the difference
between cons and cons'? With the foldr, we started with an empty
bytestring and then went over the list of numbers from the right, adding
each number to the beginning of the bytestring. When we used cons, we
ended up with one chunk for every byte, which kind of defeats the
purpose.

Otherwise, the bytestring modules have a load of functions that are
analogous to those in Data.List, including, but not limited to, head,
tail, init, null, length, map, reverse, foldl, foldr, concat, takeWhile,
filter, etc.

It also has functions that have the same name and behave the same as
some functions found in System.IO, only Strings are replaced with
ByteStrings. For instance, the readFile function in System.IO has a type
of readFile :: FilePath -\> IO String, while the readFile from the
bytestring modules has a type of readFile :: FilePath -\> IO ByteString.
Watch out, if you're using strict bytestrings and you attempt to read a
file, it will read it into memory at once! With lazy bytestrings, it
will read it into neat chunks.

Let's make a simple program that takes two filenames as command-line
arguments and copies the first file into the second file. Note that
System.Directory already has a function called copyFile, but we're going
to implement our own file copying function and program anyway.

~~~~ {.haskell:hs name="code"}
import System.Environment
import qualified Data.ByteString.Lazy as B

main = do
    (fileName1:fileName2:_) <- getArgs
    copyFile fileName1 fileName2

copyFile :: FilePath -> FilePath -> IO ()
copyFile source dest = do
    contents <- B.readFile source
    B.writeFile dest contents

Notice that a program that doesn't use bytestrings could look just like
this, the only difference is that we used B.readFile and B.writeFile
instead of readFile and writeFile. Many times, you can convert a program
that uses normal strings to a program that uses bytestrings by just
doing the necessary imports and then putting the qualified module names
in front of some functions. Sometimes, you have to convert functions
that you wrote to work on strings so that they work on bytestrings, but
that's not hard.

Whenever you need better performance in a program that reads a lot of
data into strings, give bytestrings a try, chances are you'll get some
good performance boosts with very little effort on your part. I usually
write programs by using normal strings and then convert them to use
bytestrings if the performance is not satisfactory.

Exceptions
----------

![timberr!!!!](/pages/img/timber.png)

All languages have procedures, functions, and pieces of code that might
fail in some way. That's just a fact of life. Different languages have
different ways of handling those failures. In C, we usually use some
abnormal return value (like -1 or a null pointer) to indicate that what
a function returned shouldn't be treated like a normal value. Java and
C\#, on the other hand, tend to use exceptions to handle failure. When
an exception is thrown, the control flow jumps to some code that we've
defined that does some cleanup and then maybe re-throws the exception so
that some other error handling code can take care of some other stuff.

Haskell has a very good type system. Algebraic data types allow for
types like Maybe and Either and we can use values of those types to
represent results that may be there or not. In C, returning, say, -1 on
failure is completely a matter of convention. It only has special
meaning to humans. If we're not careful, we might treat these abnormal
values as ordinary ones and then they can cause havoc and dismay in our
code. Haskell's type system gives us some much-needed safety in that
aspect. A function a -\> Maybe b clearly indicates that it it may
produce a b wrapped in Just or that it may return Nothing. The type is
different from just plain a -\> b and if we try to use those two
functions interchangeably, the compiler will complain at us.

Despite having expressive types that support failed computations,
Haskell still has support for exceptions, because they make more sense
in I/O contexts. A lot of things can go wrong when dealing with the
outside world because it is so unreliable. For instance, when opening a
file, a bunch of things can go wrong. The file might be locked, it might
not be there at all or the hard disk drive or something might not be
there at all. So it's good to be able to jump to some error handling
part of our code when such an error occurs.

Okay, so I/O code (i.e. impure code) can throw exceptions. It makes
sense. But what about pure code? Well, it can throw exceptions too.
Think about the div and head functions. They have types of (Integral a)
=\> a -\> a -\> a and [a] -\> a, respectively. No Maybe or Either in
their return type and yet they can both fail! div explodes in your face
if you try to divide by zero and head throws a tantrum when you give it
an empty list.

~~~~ {.haskell:hs name="code"}
ghci> 4 `div` 0
*** Exception: divide by zero
ghci> head []
*** Exception: Prelude.head: empty list

A very simple program. We perform the getArgs I/O action and bind the
first string in the list that it yields to fileName. Then we call the
contents of the file with that name contents. Lastly, we apply lines to
those contents to get a list of lines and then we get the length of that
list and give it to show to get a string representation of that number.
It works as expected, but what happens when we give it the name of a
file that doesn't exist?

~~~~ {.plain name="code"}
$ runhaskell linecount.hs i_dont_exist.txt
linecount.hs: i_dont_exist.txt: openFile: does not exist (No such file or directory)

We did fileExists \<- doesFileExist fileName because doesFileExist has a
type of doesFileExist :: FilePath -\> IO Bool, which means that it
returns an I/O action that has as its result a boolean value which tells
us if the file exists. We can't just use doesFileExist in an *if*
expression directly.

Another solution here would be to use exceptions. It's perfectly
acceptable to use them in this context. A file not existing is an
exception that arises from I/O, so catching it in I/O is fine and dandy.

To deal with this by using exceptions, we're going to take advantage of
the catch function from System.IO.Error. Its type is catch :: IO a -\>
(IOError -\> IO a) -\> IO a. It takes two parameters. The first one is
an I/O action. For instance, it could be an I/O action that tries to
open a file. The second one is the so-called handler. If the first I/O
action passed to catch throws an I/O exception, that exception gets
passed to the handler, which then decides what to do. So the final
result is an I/O action that will either act the same as the first
parameter or it will do what the handler tells it if the first I/O
action throws an exception.

![non sequitor](/pages/img/puppy.png)

If you're familiar with *try-catch* blocks in languages like Java or
Python, the catch function is similar to them. The first parameter is
the thing to try, kind of like the stuff in the *try* block in other,
imperative languages. The second parameter is the handler that takes an
exception, just like most *catch* blocks take exceptions that you can
then examine to see what happened. The handler is invoked if an
exception is thrown.

The handler takes a value of type IOError, which is a value that
signifies that an I/O exception occurred. It also carries information
regarding the type of the exception that was thrown. How this type is
implemented depends on the implementation of the language itself, which
means that we can't inspect values of the type IOError by pattern
matching against them, just like we can't pattern match against values
of type IO *something*. We can use a bunch of useful predicates to find
out stuff about values of type IOError as we'll learn in a second.

So let's put our new friend catch to use!

~~~~ {.haskell:hs name="code"}
import System.Environment
import System.IO
import System.IO.Error

main = toTry `catch` handler

toTry :: IO ()
toTry = do (fileName:_) <- getArgs
           contents <- readFile fileName
           putStrLn $ "The file has " ++ show (length (lines contents)) ++ " lines!"

handler :: IOError -> IO ()
handler e = putStrLn "Whoops, had some trouble!"

In the handler, we didn't check to see what kind of IOError we got. We
just say "Whoops, had some trouble!" for any kind of error. Just
catching all types of exceptions in one handler is bad practice in
Haskell just like it is in most other languages. What if some other
exception happens that we don't want to catch, like us interrupting the
program or something? That's why we're going to do the same thing that's
usually done in other languages as well: we'll check to see what kind of
exception we got. If it's the kind of exception we're waiting to catch,
we do our stuff. If it's not, we throw that exception back into the
wild. Let's modify our program to catch only the exceptions caused by a
file not existing.

~~~~ {.haskell:hs name="code"}
import System.Environment
import System.IO
import System.IO.Error

main = toTry `catch` handler

toTry :: IO ()
toTry = do (fileName:_) <- getArgs
           contents <- readFile fileName
           putStrLn $ "The file has " ++ show (length (lines contents)) ++ " lines!"

handler :: IOError -> IO ()
handler e
    | isDoesNotExistError e = putStrLn "The file doesn't exist!"
    | otherwise = ioError e

Where notifyCops and freeSomeSpace are some I/O actions that you define.
Be sure to re-throw exceptions if they don't match any of your criteria,
otherwise you're causing your program to fail silently in some cases
where it shouldn't.

System.IO.Error also exports functions that enable us to ask our
exceptions for some attributes, like what the handle of the file that
caused the error is, or what the filename is. These start with ioe and
you can see a [full list of
them](http://www.haskell.org/ghc/docs/6.10.1/html/libraries/base/System-IO-Error.html#3)
in the documentation. Say we want to print the filename that caused our
error. We can't print the fileName that we got from getArgs, because
only the IOError is passed to the handler and the handler doesn't know
about anything else. A function depends only on the parameters it was
called with. That's why we can use the ioeGetFileName function, which
has a type of ioeGetFileName :: IOError -\> Maybe FilePath. It takes an
IOError as a parameter and maybe returns a FilePath (which is just a
type synonym for String, remember, so it's kind of the same thing).
Basically, what it does is it extracts the file path from the IOError,
if it can. Let's modify our program to print out the file path that's
responsible for the exception occurring.

~~~~ {.haskell:hs name="code"}
import System.Environment
import System.IO
import System.IO.Error

main = toTry `catch` handler

toTry :: IO ()
toTry = do (fileName:_) <- getArgs
           contents <- readFile fileName
           putStrLn $ "The file has " ++ show (length (lines contents)) ++ " lines!"

handler :: IOError -> IO ()
handler e
    | isDoesNotExistError e =
        case ioeGetFileName e of Just path -> putStrLn $ "Whoops! File does not exist at: " ++ path
                                 Nothing -> putStrLn "Whoops! File does not exist at unknown location!"
    | otherwise = ioError e