User:Duplode/Haskell leftovers 2

From Wikibooks, open books for an open world
Jump to navigation Jump to search

Revised sections of Next Steps[edit | edit source]

case[edit | edit source]

Haskell, like many other languages, also supports case constructions. These are used when there are multiple values that you want to check against (case expressions are actually quite a bit more powerful than this – see the Pattern matching chapter for all of the details).

Suppose we wanted to define a function that had a value of if its argument were ; a value of if its argument were ; a value of if its argument were ; and a value of in all other instances. Writing this function using if statements would be long and very unreadable; so we write it using a case statement as follows (we call this function f):


f x =
    case x of
      0 -> 1
      1 -> 5
      2 -> 2
      _ -> -1

In this program, we're defining f to take an argument x and then inspecting the value of x. If it matches , the value of f is . If it matches , the value of f is . If it matches , then the value of f is ; and if it hasn't matched anything by that point, the value of f is (the underscore can be thought of as a "wildcard" – it will match anything).

The indentation here is important. Haskell uses a system called "layout" to structure its code (the programming language Python uses a similar system). The layout system allows you to write code without the explicit semicolons and braces that other languages like C and Java require.

Indentation[edit | edit source]

The general rule for layout is that an opening brace (the { character) is inserted after the keywords where, let, do and of, and the column position at which the next command appears is remembered. From then on, a semicolon is inserted before every new line that is indented the same amount. If a following line is indented less, a closing brace (}) is inserted. This may sound complicated, but if you follow the general rule of indenting after each of those keywords, you'll never have to remember it (see the Indentation chapter for a more complete discussion of layout).

Some people prefer not to use layout and write the braces and semicolons explicitly. This is perfectly acceptable. In this style, the above function might look like:

f x = case x of
        { 0 -> 1 ; 1 -> 5 ; 2 -> 2 ; _ -> -1 }

Of course, if you write the braces and semicolons explicitly, you're free to structure the code as you wish. The following is also equally valid:

f x =
    case x of { 0 -> 1 ;
      1 -> 5 ; 2 -> 2
   ; _ -> -1 }

However, structuring your code like this only serves to make it unreadable (in this case).

Defining one function for different parameters[edit | edit source]

Functions can also be defined piece-wise, meaning that you can write one version of your function for certain parameters and then another version for other parameters. For instance, the above function f could also be written as:


f 0 = 1
f 1 = 5
f 2 = 2
f _ = -1

Just like in the case situation above, order is important. If we had put the last line first, it would have matched every argument, and f would return -1, regardless of its argument (most compilers will warn you about this, though, saying something about overlapping patterns). If we had not included this last line, f would produce an error if anything other than 0, 1 or 2 were applied to it (most compilers will warn you about this, too, saying something about incomplete patterns). This style of piece-wise definition is very popular and will be used quite frequently throughout this tutorial. These two definitions of f are actually equivalent – this piece-wise version is translated into the case expression.

Function composition[edit | edit source]

More complicated functions can be built from simpler functions using function composition. Function composition is simply taking the result of the application of one function and using that as an argument for another. We've already seen this back in the Getting set up chapter, when we wrote 5*4+3. In this, we were evaluating and then applying to the result. We can do the same thing with our square and f functions:


square x = x^2
*Main> square (f 1)
*Main> square (f 2)
*Main> f (square 1)
*Main> f (square 2)

The result of each of these function applications is fairly straightforward. The parentheses around the inner function are necessary; otherwise, in the first line, the interpreter would think that you were trying to get the value of square f, which has no meaning. Function application like this is fairly standard in most programming languages.

There is another, more mathematical way to express function composition: the (.) enclosed period function. This (.) function is modeled after the () operator in mathematics.


In mathematics we write to mean "f following g." In Haskell , we write f . g also to mean "f following g."

The meaning of is simply that . That is, applying the function to the value is the same as applying to , taking the result, and then applying to that.

The (.) function (called the function composition function), takes two functions and makes them into one. For instance, if we write (square . f), this means that it creates a new function that takes an argument, applies f to that argument and then applies square to the result. Conversely, (f . square) means that a new function is created that takes an argument, applies square to that argument and then applies f to the result. We can see this by testing it as before:


*Main> (square . f) 1
*Main> (square . f) 2
*Main> (f . square) 1
*Main> (f . square) 2

Here, we must enclose the function composition in parentheses; otherwise, the Haskell compiler will think we're trying to compose square with the value f 1 in the first line, which makes no sense since f 1 isn't even a function.

Remotions from Simple I/O[edit | edit source]

Controlling actions[edit | edit source]


We can write the same doGuessing function using a case statement. To do this, we first introduce the Prelude function compare, which takes two values of the same type (in the Ord class) and returns a value of type Ordering, namely one of GT, LT, EQ, depending on whether the first is greater than, less than or equal to the second.

doGuessing num = do
  putStrLn "Enter your guess:"
  guess <- getLine
  case compare (read guess) num of
    LT -> do putStrLn "Too low!"
             doGuessing num
    GT -> do putStrLn "Too high!"
             doGuessing num
    EQ -> putStrLn "You Win!"

Here, again, the dos after the ->s are necessary on the first two options, because we are sequencing actions.

If you're used to programming in an imperative language like C or Java, you might think that return will exit you from the current function. This is not so in Haskell. In Haskell, return simply takes a normal value (for instance, one of type Int) and makes it into an action that when evaluated, gives the given value (for the same example, the action would be of type IO Int). In particular, in an imperative language, you might write this function as:

void doGuessing(int num) {
  print "Enter your guess:";
  int guess = atoi(readLine());
  if (guess == num) {
    print "You win!";
    return ();

  // we won't get here if guess == num
  if (guess < num) {
    print "Too low!";
  } else {
    print "Too high!";

Here, because we have the return () in the first if match, we expect the code to exit there (and in most imperative languages, it does). However, the equivalent code in Haskell, which might look something like:

doGuessing num = do
  putStrLn "Enter your guess:"
  guess <- getLine
  case compare (read guess) num of
    EQ -> do putStrLn "You win!"
             return ()

  -- we don't expect to get here if guess == num
  if (read guess < num)
    then do print "Too low!";
            doGuessing num
    else do print "Too high!";
            doGuessing num

First of all, if you guess correctly, it will first print "You win!," but it won't exit, and it will check whether guess is less than num. Of course it is not, so the else branch is taken, and it will print "Too high!" and then ask you to guess again.

On the other hand, if you guess incorrectly, it will try to evaluate the case statement and get either LT or GT as the result of the compare. In either case, it won't have a pattern that matches, and the program will fail immediately with an exception.


What does the following program print out?

main =
 do x <- getX
    putStrLn x

getX =
 do return "hello"
    return "aren't"
    return "these"
    return "returns"
    return "rather"
    return "pointless?"

Write a program that asks the user for his or her name. If the name is one of Simon, John or Phil, tell the user that you think Haskell is a great programming language. If the name is Koen, tell them that you think debugging Haskell is fun (Koen Classen is one of the people who works on Haskell debugging); otherwise, tell the user that you don't know who he or she is.

Write two different versions of this program, one using if statements, the other using a case statement.

Pattern matching (Where you can use pattern matching)[edit | edit source]

Case expressions[edit | edit source]

Another typical usage of pattern binding is on the left hand side of case branches:

describeList :: (Show a) => [a] -> String
describeList list = 
  case list of
   []     -> "The list was empty"
   (x:xs) -> "The list wasn't empty: the first element was " ++ show x ++ ", and " ++
             "there were " ++ show (length xs) ++ " more elements in the list."

Other places[edit | edit source]

There are a few other situations in which patterns can be used that we'll meet later on. Here's a list in case you're very eager already:

  • where clauses, which are an alternative to let bindings;
  • lambdas, which are anonymous function definitions;
  • In p <- x assignments in do-blocks, p can be a pattern.
  • Similarly, with let bindings in do-blocks, you can pattern match analogously to 'real' let bindings.