Lesson 2: Input and Output, Variable Binding, and more

Overview

Today we will be examining this simple program:

module Main where

main =
    do putStrLn "What is your name?"
       name <- getLine
       putStrLn ("Hello, " ++ name ++ ". I think you will really like Haskell!")

Copy this code into a file named HelloYou.hs, and then run it in GHCi (C-c C-l, and then run the main function), or compile it an run it (M-C ghc --make -O2 HelloYou.hs -o helloYou).

Files containing Haskell source code will almost always end with the extention .hs. You should follow this convention as well, because the compiler expects it.

do notation

The first new thing we see is the do keyword. In this context, the do keyword indicates that we want to perform several IO (input/output) actions in a row.

Notice how each action is indented the same amount. In Haskell, the layout of the code is significant. The do statement automatically ends when a line that is indented less is encountered.

For example, in this code:

main =
    do putStrLn "What is your name?"
       name <- getLine
       putStrLn ("Hello, " ++ name ++ ". I think you will really like Haskell!")

cheese = "cheddar"

Because cheese = "cheddar" starts at the first column, it is not part of the previous do statement. The blank line before cheese is ignored.

If a line is indented more, then it is considered to be a continuation of the previous line. For example, we can reformat our program so that the third action is split across two lines:

main =
    do putStrLn "What is your name?"
       name <- getLine
       putStrLn ("Hello, " ++ name ++ 
                 ". I think you will really like Haskell!")

The meaning is not changed at all.

Variable Binding

The next new thing we see is this line:

       name <- getLine

getLine is an IO action that reads a line of input from stdin. The <- operator binds the variable name to the value read by getLine.

What Does bind Mean?

You can imagine that the value returned by getLine is a cardboard box with a String inside. binding name to the value is like putting a label on the cardboard box. This makes it easy to refer to that value later, because we can just use the variable name.

Not Like Variables You Have Seen Before

If you have used other programming languages, you are probably familiar with a different kind of variable. For example, in C, you would declare a variable i and assign it the value 9 like this:

    int i;
    i = 9;

This called a destructive update and is different than binding a variable. If we think about the box analogy, the statement int i; creates a new cardboard box with the label i already attached to it. The statement i = 9; opens up the box, destroys the current contents, and then puts 9 in the box.

This difference is pretty substantial -- just imagine how you would feel if you were still using the old contents of the box! We will cover this concept more in a few lessons, and see why the difference is so exciting.

The ++ operator

The next new thing we see is the ++ operator. ++ concatenates two lists together and returns a new list. In Haskell, a String is just a list a characters.

Where did those () come from?

In the first lesson, we noted that Haskell does not require you to use parentheses when calling a function; but now we have some parentheses, so what's the deal? The parentheses in Haskell are used to group operations, in the same way you would in math.

So in this line:

       putStrLn ("Hello, " ++ name ++ ". I think you will really like Haskell!")

The parentheses indicated that we want to concatenate the strings first, and then apply putStrLn to the new string. If we did not use parentheses, the compiler would add implicit parentheses like this:

       (putStrLn "Hello, ") ++ (name ++ ". I think you will really like Haskell!")

which does not make any sense; it says we want to print the string Hello , and then append the String, (name ++ ". I think you will really like Haskell!"), to the value returned by putStrLn.

No Variable Declarations, But Still Safe

In our program, we use a variable called name. You may have noticed that we did not declare that variable before we started using it. That saves us some typing, which is nice, but what happens if we make a typo and spell it nmae? Let's load this code into GHCi and see:

module Main where

main =
    do putStrLn "What is your name?"
       name <- getLine
       putStrLn ("Hello, " ++ nmae ++ ". I think you will really like Haskell!")

GHCi reports the following error:

*Main> :load "/root/n-heptane/docs/haskell-lessons/HelloYou.hs"
[1 of 1] Compiling Main             ( /root/n-heptane/docs/haskell-lessons/HelloYou.hs, interpreted )

/root/n-heptane/docs/haskell-lessons/HelloYou.hs:6:30:
    Not in scope: `nmae'
Failed, modules loaded: none.
Prelude> 

Nice! GHC tells us that the identifier `nmae' at line 6, column 30, is not defined. Notice that we have not tried to run the code yet, the bug was detected at compile time. So, we get the best of both worlds: we don't have to tell the compiler about our variables before we use them, but the compiler can still tell us if we accidentally use an undefined variable.

Cool Stuff We Learned Today

Today's code example was pretty simple, but, we managed to avoid four extremely common bugs that have been responsible for thousands of security holes and program crashes.

Safe from Buffer Overflows

The first two bugs we avoid are buffer overflows. Buffer overflows are an extremely common source of security holes and program crashes. Buffer overflows occur when a string is too big to fit in the space allocated for it, or when some code thinks a string is longer than it really is, and tries to read characters beyond the end of the string.

Two common places to encounter buffer overflows are when you are reading input and receive more input than you expected, or when you are concatenating strings and don't allocate enough space, or you accidentally copy too much data.

In our code sample of the day, we read input with getLine and concatenate Strings with ++. But, we never had to worry about how long the Strings were, it was all handled automatically for us.

Safety from buffer overflows is nice, but does not really set Haskell apart. Many other languages, such as Java, Python, Perl, Ruby, etc, are also safe from buffer overflows in this way (as far as I known). So let's look at the next two bugs we managed to avoid, which are a bit more interesting.

Safe from Uninitialized Variables

We saw earlier that when we misspelled name as nmae, the compiler caught our mistake. It noticed that we were trying to use the variable nmae, but nmae had not been bound to anything yet.

This is really nice! In many languages that do not required you to declare your variables in advance, you would not notice this bug until you ran the program. In some cases the program would die when it tried to use nmae. In other cases, it would just assume that nmae was equal to the empty string "", so you might not even notice the problem!

Even in languages where you have to declare your variables in advance, we are susceptible to a similar bug. Consider the following C code:

    int a;
    int b;
    int c;

    b = 1;
    c = a + b;
    printf("%d\n", c);

Even though we declared our variables a,b, and c, I forgot to assign a value to a. This means that when try to use a to calculate c we have absolutely no idea what will happen. On my system c was equal to -1077263575 the first time I ran it, and -1080545591 the second time.

Fortunately, Haskell goes the extra step and requires that all the variables we use are actually bound to a value, so we will not be seeing of those nasty behaviors.

How It Looks Is Meaningful

We saw in this lesson that the formatting of the code is important to the compiler. This is nice because the code looks pretty, and we don't have to type in lots of extra characters like (){};. But it also helps us avoid bugs. Almost all programmers try to format their code so that you can understand the flow of the code by the way it looks. But, in most languages, the compiler does not care how the code looks. Consider the following C code:

    if (something)
        doSomething();
        doSomethingElse();

    doSomethingToo();

Even though doSomethingElse() looks like it is inside the if statement, it is not. The compiler reads it like this:

    if (something)
        doSomething();

    doSomethingElse();
    doSomethingToo();

Ouch! Since Haskell does care about the formatting, you are far less likely to see things differently than the compiler does.

Summary

Well, I think I went over my time again, but there was a lot of new material, even though today's program was only two lines longer than yesterday's. Next time we will learn about the case statement. This will allow us to do different things depending on what the user enters.

You don't need to memorize or perfectly understand everything in this lesson. We will be exploring these concepts more in the upcoming lessons, which should help you to remember and understand them.

emacs corner: TAB indenting

In the previous lesson, we saw that using emacs makes it easy to load programs into GHCi. You probably also noticed that emacs colored the source code for you. In this lesson, we learned that the indentation of each line is significant. emacs can help here too. If you copied and pasted the code into emacs try typing it in by hand instead. When you need to indent a line, press the TAB key a couple times in a row. You will see that emacs cycles through the different possibilities. Personally, I find this feature extremely useful.