View source for Haskell/Next steps

{{clear}}
{{Haskell minitoc|chapter=Haskell Basics|noexercises=0}}

This chapter introduces ''pattern matching'' and two new pieces of syntax: <code>if</code> expressions and <code>let</code> bindings.

== if / then / else ==

Haskell syntax supports garden-variety conditional expressions of the form ''if... then... else...'' . For instance, consider a function that returns <code>(-1)</code> if its argument is less than <code>0</code>; <code>0</code> if its argument ''is'' <code>0</code>; and <code>1</code> if its argument is greater than <code>0</code>. The predefined <code>signum</code> function does that job already; but for the sake of illustration, let's define a version of our own:

{{HaskellExample|The signum function.|
<syntaxhighlight lang="haskell">
mySignum x =
    if x < 0 
        then -1
        else if x > 0
            then 1
            else 0
</syntaxhighlight>
You can experiment with this:

{{HaskellGHCi|1=
*Main> mySignum 5
1
*Main> mySignum 0
0
*Main> mySignum (5 - 10)
-1
*Main> mySignum (-1)
-1
}}}}

The parentheses around "-1" in the last example are required; if missing, Haskell will think that you are trying to subtract <code>1</code> from <code>mySignum</code> (which would give a type error).

In an if/then/else construct, first the condition (in this case <code>x < 0</code>) is evaluated. If it results <code>True</code>, the whole construct evaluates to the <tt>'''then'''</tt> expression; otherwise (if the condition is <code>False</code>), the construct evaluates to the <tt>'''else'''</tt> expression. All of that is pretty intuitive. If you have programmed in an imperative language before, however, it might seem surprising to know that Haskell always requires ''both'' a <tt>'''then'''</tt> ''and'' an <tt>'''else'''</tt> clause. The construct has to result in a value in both cases and, specifically, a value of the same type in both cases.

Function definitions using if / then / else like the one above can be rewritten using [[../Truth_values#Guards|Guards]].

{{HaskellExample|1=From if to guards|2=<syntaxhighlight lang="haskell">
mySignum x
    | x < 0     = -1
    | x > 0     = 1
    | otherwise = 0
</syntaxhighlight>}}

Similarly, the absolute value function defined in [[../Truth_values#Guards/|Truth values]] can be rendered with an if/then/else:

{{HaskellExample|1=From guards to if|2=<syntaxhighlight lang="haskell">
absolute x =
    if x < 0 
        then -x
        else x
</syntaxhighlight>}}

Why use if/then/else versus guards? As you will see with later examples and in your own programming, either way of handling conditionals may be more readable or convenient depending on the circumstances. In many cases, both options work equally well.

== Introducing pattern matching ==

Consider a program which tracks statistics from a racing competition in which racers receive points based on their classification in each race, the scoring rules being:
* 10 points for the winner;
* 6 for second-placed;
* 4 for third-placed;
* 3 for fourth-placed;
* 2 for fifth-placed;
* 1 for sixth-placed;
* no points for other racers.
We can write a simple function which takes a classification (represented by an integer number: <code>1</code> for first place, etc.<ref>Here we will not be much worried about what happens if a nonsensical value (say, <code>(-4)</code>) is passed to the function. In general, however, it is a good idea to give some thought to such "strange" cases, in order to avoid nasty surprises down the road.</ref>) and returns how many points were earned. One possible solution uses if/then/else:

{{HaskellExample|1=Computing points with if/then/else|2=<syntaxhighlight lang="haskell">
pts :: Int -> Int
pts x =
    if x == 1
        then 10
        else if x == 2
            then 6
            else if x == 3
                then 4
                else if x == 4
                    then 3
                    else if x == 5
                        then 2
                        else if x == 6
                            then 1
                            else 0
</syntaxhighlight>}}

Yuck! Admittedly, it wouldn't look this hideous had we used guards instead of if/then/else, but it still would be tedious to write (and read!) all those equality tests. We can do better, though:

{{HaskellExample|1=Computing points with a piece-wise definition|2=<syntaxhighlight lang="haskell">
pts :: Int -> Int
pts 1 = 10
pts 2 = 6
pts 3 = 4
pts 4 = 3
pts 5 = 2
pts 6 = 1
pts _ = 0
</syntaxhighlight>}}

''Much'' better. However, even though defining <code>pts</code> in this style (which we will arbitrarily call ''piece-wise definition'' from now on) shows to a reader of the code what the function does in a clear way, the syntax looks odd given what we have seen of Haskell so far. Why are there seven equations for <code>pts</code>? What are those numbers doing in their left-hand sides? What about variable arguments?

This feature of Haskell is called ''pattern matching''. When we call <code>pts</code>, the argument is ''matched'' against the numbers on the left side of each of the equations, which in turn are the ''patterns''. The matching is done in the order we wrote the equations. First, the argument is matched against the <code>1</code> in the first equation. If the argument is indeed <code>1</code>, we have a match and the first equation is used; so <code>pts 1</code> evaluates to <code>10</code> as expected. Otherwise, the other equations are tried in order following the same procedure. The final one, though, is rather different: the <code>_</code> is a special pattern, often called a "wildcard", that might be read as "whatever": it matches with anything; and therefore if the argument doesn't match any of the previous patterns <code>pts</code> will return zero.

As for the lack of <code>x</code> or any other variable standing for the argument, we simply don't need that to write the definitions. All possible return values are constants. Besides, variables are used to express relationships on the right side of the definition, so the <code>x</code> is unnecessary in our <code>pts</code> function.

However, we could use a variable to make <code>pts</code> even more concise. The points given to a racer decrease regularly from third place to sixth place, at a rate of one point per position. After noticing that, we can eliminate three of the seven equations as follows:

{{HaskellExample|1=Mixing styles|2=<syntaxhighlight lang="haskell">
pts :: Int -> Int
pts 1 = 10
pts 2 = 6
pts x
    | x <= 6    = 7 - x
    | otherwise = 0
</syntaxhighlight>}}

So, we can mix both styles of definitions. In fact, when we write <code>pts x</code> in the left side of an equation we are using pattern matching too! As a pattern, the <code>x</code> (or any other variable name) matches anything just like <code>_</code>; the only difference being that it also gives us a name to use on the right side (which, in this case, is necessary to write <code>7 - x</code>).

{{Exercises|1=
We cheated a little when moving from the second version of <code>pts</code> to the third one: they do not do exactly the same thing. Can you spot what the difference is?
}}

Beyond integers, pattern matching works with values of various other types. One handy example is booleans. For instance, the <code>(||)</code> logical-or operator we met in [[../Truth values#Boolean operators|Truth values]] could be defined as:

{{HaskellExample|1=<code>({{!!}})</code>|2=<syntaxhighlight lang="haskell">
(||) :: Bool -> Bool -> Bool
False || False = False
_     || _     = True
</syntaxhighlight>}} 

Or:

{{HaskellExample|1=<code>({{!!}})</code>, done another way|2=<syntaxhighlight lang="haskell">
(||) :: Bool -> Bool -> Bool
True  || _ = True
False || y = y
</syntaxhighlight>}} 

When matching two or more arguments at once, the equation will only be used if all of them match.

Now, let's discuss a few things that might go wrong when using pattern matching:

* If we put a pattern which matches anything (such as the final patterns in each of the <code>pts</code> example) ''before'' the more specific ones the latter will be ignored. GHC(i) will typically warn us that "Pattern match(es) are overlapped" in such cases.
* If no patterns match, an error will be triggered. Generally, it is a good idea to ensure the patterns cover all cases, in the same way that the <code>otherwise</code> guard is not mandatory but highly recommended.
* Finally, while you can play around with various ways of (re)defining <code>(&&),</code><ref>If you are going to experiment with it in GHCi, call your version something else to avoid a name clash; say, (&!&).</ref> here is one version that will ''not'' work:

<syntaxhighlight lang="haskell">
(&&) :: Bool -> Bool -> Bool
x && x = x -- oops!
_ && _ = False
</syntaxhighlight>

:The program won't test whether the arguments are equal just because we happened to use the same name for both. As far as the matching goes, we could just as well have written <code>_ && _</code> in the first case. And even worse: because we gave the same name to both arguments, GHC(i) will refuse the function due to "Conflicting definitions for `x'".

== Tuple and list patterns ==

While the examples above show that pattern matching helps in writing more elegant code, that does not explain why it is so important. So, let's consider the problem of writing a definition for <code>fst</code>, the function which extracts the first element of a pair. At this point, that appears to be an impossible task, as the only way of accessing the first value of the pair is by using <code>fst</code> itself... The following function, however, does the same thing as <code>fst</code> (confirm it in GHCi):

{{HaskellExample|1=A definition for <code>fst</code>|2=<syntaxhighlight lang="haskell">
fst' :: (a, b) -> a
fst' (x, _) = x
</syntaxhighlight>}}

It's magic! Instead of using a regular variable in the left side of the equation, we specified the argument with the ''pattern'' of the 2-tuple - that is, <code>(,)</code> - filled with a variable and the <code>_</code> pattern. Then the variable was automatically associated with the first component of the tuple, and we used it to write the right side of the equation. The definition of <code>snd</code> is, of course, analogous.

Furthermore, the trick demonstrated above can be done with lists as well. Here are the actual definitions of <code>head</code> and <code>tail</code>:

{{HaskellExample|1=<code>head</code>, <code>tail</code> and patterns|2=<syntaxhighlight lang="haskell">
head             :: [a] -> a
head (x:_)       =  x
head []          =  error "Prelude.head: empty list"

tail             :: [a] -> [a]
tail (_:xs)      =  xs
tail []          =  error "Prelude.tail: empty list"
</syntaxhighlight>}}

The only essential change in relation to the previous example was replacing <code>(,)</code> with the pattern of the cons operator <code>(:)</code>. These functions also have an equation using the pattern of the empty list, <code>[]</code>; however, since empty lists have no head or tail there is nothing to do other than use <code>error</code> to print a prettier error message.

In summary, the power of pattern matching comes from its use in accessing the parts of a complex value. Pattern matching on lists, in particular, will be extensively deployed in [[../Recursion|Recursion]] and the chapters that follow it. Later on, we will explore what is happening behind this seemingly magical feature.

== <tt>let</tt> bindings ==

To conclude this chapter, a brief word about <code>let</code> bindings (an alternative to <code>where</code> clauses for making local declarations). For instance, take the problem of finding the roots of a polynomial of the form <math>ax^2+bx+c</math> (in other words, the solution to a second degree equation — think back to your middle school math courses). Its solutions are given by:
: <math>x = \frac {-b \pm \sqrt{b^2-4ac}} {2a}</math>.
We could write the following function to compute the two values of <math>x</math>:

<syntaxhighlight lang="haskell">
roots a b c =
    ((-b + sqrt(b * b - 4 * a * c)) / (2 * a),
     (-b - sqrt(b * b - 4 * a * c)) / (2 * a))
</syntaxhighlight>

Writing the <code>sqrt(b * b - 4 * a * c)</code> term in both cases is annoying, though; we can use a local binding instead, using either <code>where</code> or, as will be demonstrated below, a <code>let</code> declaration:

<syntaxhighlight lang="haskell">
roots a b c =
    let sdisc = sqrt (b * b - 4 * a * c)
    in  ((-b + sdisc) / (2 * a),
         (-b - sdisc) / (2 * a))
</syntaxhighlight>
We put the <code>let</code> keyword before the declaration, and then use <code>in</code> to signal we are returning to the "main" body of the function. It is possible to put multiple declarations inside a single <code>let</code>...<code>in</code> block — just make sure they are indented the same amount or there will be syntax errors:

<syntaxhighlight lang="haskell">
roots a b c =
    let sdisc = sqrt (b * b - 4 * a * c)
        twice_a = 2 * a
    in  ((-b + sdisc) / twice_a,
         (-b - sdisc) / twice_a)
</syntaxhighlight>

{{warning|1=
Because indentation matters syntactically in Haskell, you need to be careful about whether you are using tabs or spaces. By far the best solution is to configure your text editor to insert two or four spaces in place of tabs. If you insist on keeping tabs as distinct, at least ensure that your tabs always have the same length.
}}

{{body note|1=
The [[../Indentation|Indentation]] chapter has a full account of indentation rules.
}}

{{Haskell/NotesSection}}

{{Haskell navigation|chapter=Haskell Basics}}

{{Auto category}}