4Case Expressions and Pattern Matching

Earlier we gave several examples of pattern matching in defining
functions---for example length and fringe. In this section we
will look at the pattern-matching process in greater detail
(§3.17). (Pattern matching in Haskell is
different from that found in logic programming languages such as
Prolog; in particular, it can be viewed as "one-way" matching,
whereas Prolog allows "two-way" matching (via unification), along
with implicit backtracking in its evaluation mechanism.)

Patterns are not "first-class;" there is only a fixed set of
different kinds of patterns. We have already seen several examples of
data constructor patterns; both length and fringe defined
earlier use such patterns, the former on the constructors of a
"built-in" type (lists), the latter on a user-defined type (Tree).
Indeed, matching is permitted using the constructors of any type,
user-defined or not. This includes tuples, strings, numbers,
characters, etc. For example, here's a contrived function that
matches against a tuple of "constants:"

This example also demonstrates that nesting of patterns is
permitted (to arbitrary depth).

Technically speaking, formal parameters (The Report
calls these variables.) are also patterns---it's just that they
never fail to match a value. As a "side effect" of the
successful match, the formal parameter is bound to the value it is
being matched against. For this reason patterns in any one equation
are not allowed to have more than one occurrence of the same formal
parameter (a property called linearity§3.17,
§3.3,§4.4.2).

Patterns such as formal parameters that never fail to match are said
to be irrefutable, in contrast to refutable patterns which
may fail to match. The pattern used
in the contrived example above is refutable. There are three
other kinds of irrefutable patterns, two of which we will introduce
now (the other we will delay until Section 4.4).

As-patterns.

Sometimes it is convenient to name a
pattern for use on the right-hand side of an equation. For example, a
function that duplicates the first element in a list might be written
as:

f (x:xs) = x:x:xs

(Recall that ":" associates to the right.) Note that x:xs appears
both as a pattern on the left-hand side, and an expression on the
right-hand side. To improve readability, we might prefer to write
x:xs just once, which we can achieve using an as-pattern as
follows: (Another advantage to doing this is that a naive
implementation might completely reconstruct x:xs rather than
re-use the value being matched against.)

f s@(x:xs) = x:s

Technically speaking, as-patterns always result in a successful match,
although the sub-pattern (in this case x:xs) could, of course, fail.

Wild-cards.

Another common situation is matching against
a value we really care nothing about. For example, the functions
head and tail defined in Section 2.1
can be rewritten as:

head (x:_) = x
tail (_:xs) = xs

in which we have "advertised" the fact that we don't care what a
certain part of the input is. Each wild-card independently matches
anything, but in contrast to a formal parameter, each binds
nothing; for this reason more than one are allowed in an equation.

4.1Pattern-Matching Semantics

So far we have discussed how individual patterns are matched, how some
are refutable, some are irrefutable, etc. But what drives the overall
process? In what order are the matches attempted? What if none
succeed? This section addresses these questions.

Pattern matching can either fail, succeed or
diverge. A successful match binds the formal parameters in the
pattern. Divergence occurs when a value needed by the pattern
contains an error (_|_). The matching process itself occurs "top-down,
left-to-right." Failure of a pattern anywhere in one equation
results in failure of the whole equation, and the next equation is
then tried. If all equations fail, the value of the function
application is _|_, and results in a run-time error.

For example, if [1,2] is matched against [0,bot], then 1 fails
to match 0, so the result is a failed match. (Recall that bot,
defined earlier, is a variable bound to _|_.) But if [1,2] is
matched against [bot,0], then matching 1 against bot causes
divergence (i.e. _|_).

The only other twist to this set of rules is that top-level patterns
may also have a boolean guard, as in this definition of a
function that forms an abstract version of a number's sign:

sign x | x > 0 = 1
| x == 0 = 0
| x < 0 = -1

Note that a sequence of guards may be provided for the same pattern;
as with patterns, they are evaluated top-down, and the first that
evaluates to True results in a successful match.

4.2An Example

The pattern-matching rules can have subtle effects on the meaning of
functions. For example, consider this definition of take:

take 0 _ = []
take _ [] = []
take n (x:xs) = x : take (n-1) xs

and this slightly different version (the first 2 equations have been
reversed):

take1 _ [] = []
take1 0 _ = []
take1 n (x:xs) = x : take1 (n-1) xs

Now note the following:

take 0 bot

=>

[]

take1 0 bot

=>

_|_

take bot []

=>

_|_

take1 bot []

=>

[]

We see that take is "more defined" with respect to its second
argument, whereas take1 is more defined with respect to its first.
It is difficult to say in this case which definition is better. Just
remember that in certain applications, it may make a difference. (The
Standard Prelude includes a definition corresponding to take.)

4.3Case Expressions

Pattern matching provides a way to "dispatch control" based on
structural properties of a value. However, in many circumstances we
don't wish to define a function every time we need to do this,
but so far we have only shown how to do pattern matching in function
definitions. Haskell's case expression provides a way to solve
this problem. Indeed, the meaning of pattern matching in function
definitions is specified in the Report in terms of case expressions,
which are considered more primitive. In particular, a function
definition of the form:

f p11 ... p1k= e1

...

f pn1 ... pnk= en

where each pij is a pattern, is semantically equivalent to:

f x1 x2 ... xk = case (x1, ..., xk) of

(p11, ..., p1k) -> e1

...

(pn1, ..., pnk) -> en

where the xi are new identifiers. (For a more general translation
that includes guards, see §4.4.2.) For example, the
definition of take given earlier is equivalent to:

A point not made earlier is that, for type correctness, the types of
the right-hand sides of a case expression or set of equations
comprising a function definition must all be the same; more precisely,
they must all share a common principal type.

The pattern-matching rules for case expressions are the same as we
have given for function definitions, so there is really nothing new to
learn here, other than to note the convenience that case expressions
offer. Indeed, there's one use of a case expression that is so common
that it has special syntax: the conditional expression. In
Haskell, conditional expressions have the familiar form:

if e1then e2else e3

which is really short-hand for:

case e1of

True -> e2

False -> e3

From this expansion it should be clear that e1 must have type
Bool, and e2 and e3 must have the same (but otherwise
arbitrary) type. In other words, if_then_else_when viewed
as a function has type Bool->a->a->a.

4.4Lazy Patterns

There is one other kind of pattern allowed in Haskell. It is called a
lazy pattern, and has the form ~pat. Lazy patterns are
irrefutable: matching a value v against ~pat always
succeeds, regardless of pat. Operationally speaking, if an
identifier in pat is later "used" on the right-hand-side, it will
be bound to that portion of the value that would result if v were to
successfully match pat, and _|_ otherwise.

Lazy patterns are useful in contexts where infinite data structures are being
defined recursively. For example, infinite lists are an excellent
vehicle for writing simulation programs, and in this context the
infinite lists are often called streams. Consider the simple
case of simulating the interactions between a server process server
and a client process client, where client sends a sequence of
requests to server, and server replies to each request with some
kind of response. This situation is shown pictorially in Figure
2, just as we did with the Fibonacci example. (Note
that client also takes an initial message as argument.)

Figure 2

Using
streams to simulate the message sequences, the Haskell code
corresponding to this diagram is:

reqs = client init resps
resps = server reqs

These recursive equations are a direct lexical transliteration of the
diagram.

Let us further assume that the structure of the server and client look
something like this:

where we assume that next is a function that, given a response from
the server, determines the next request, and process is a function
that processes a request from the client, returning an appropriate
response.

Unfortunately, this program has a serious problem: it will not produce
any output! The problem is that client, as used in the recursive
setting of reqs and resps, attempts a match on the response list
before it has submitted its first request! In other words, the
pattern matching is being done "too early." One way to fix this is
to redefine client as follows:

client init resps = init : client (next (head resps)) (tail resps)

Although workable, this solution does not read as well as that given
earlier. A better solution is to use a lazy pattern:

client init ~(resp:resps) = init : client (next resp) resps

Because lazy patterns are irrefutable, the match will immediately
succeed, allowing the initial request to be "submitted," in turn
allowing the first response to be generated; the engine is now
"primed," and the recursion takes care of the rest.

As an example of this program in action, if we define:

init = 0
next resp = resp
process req = req+1

then we see that:

take 10 reqs => [0,1,2,3,4,5,6,7,8,9]

As another example of the use of lazy patterns, consider the
definition of Fibonacci given earlier:

fib = 1 : 1 : [ a+b | (a,b) <- zip fib (tail fib) ]

We might try rewriting this using an as-pattern:

fib@(1:tfib) = 1 : 1 : [ a+b | (a,b) <- zip fib tfib ]

This version of fib has the (small) advantage of not using tail on
the right-hand side, since it is available in "destructured" form on
the left-hand side as tfib.

[This kind of equation is called a pattern binding because
it is a top-level equation in which the entire left-hand side is a
pattern; i.e. both fib and tfib become bound within the scope of
the declaration.]

Now, using the same reasoning we did earlier, we should be led to
believe that this program will not generate any output. Curiously,
however, it does, and the reason is simple: in Haskell,
pattern bindings are assumed to have an implicit ~ in front of them,
reflecting the most common behavior expected of pattern bindings, and
avoiding some anomalous situations which are beyond the scope of this
tutorial. Thus we see that lazy patterns play an important role in
Haskell, if only implicitly.

4.5Lexical Scoping and Nested Forms

It is often desirable to create a nested scope within an expression,
for the purpose of creating local bindings not seen elsewhere---i.e.
some kind of "block-structuring" form. In Haskell there are two ways
to achieve this:

Let Expressions.

Haskell's let expressions are
useful whenever a nested set of bindings is required. As a simple
example, consider:

let y = a*b
f x = (x+y)/y
in f c + f d

The set of bindings created by a let expression is mutually
recursive, and pattern bindings are treated as lazy patterns (i.e.
they carry an implicit ~). The only kind of declarations permitted
are type signatures, function bindings, and pattern
bindings.

Where Clauses.

Sometimes it is convenient to scope
bindings over several guarded equations, which requires a where
clause:

f x y | y>z = ...
| y==z = ...
| y<z = ...
where z = x*x

Note that this cannot be done with a let expression, which only
scopes over the expression which it encloses. A where clause is
only allowed at the top level of a set of equations or case
expression. The same properties and constraints on bindings in let
expressions apply to those in where clauses.

These two forms of nested scope seem very similar, but remember that a
let expression is an expression, whereas a where clause is
not---it is part of the syntax of function declarations and case
expressions.

4.6Layout

The reader may have been wondering how it is that Haskell programs
avoid the use of semicolons, or some other kind of terminator, to
mark the end of equations, declarations, etc. For example, consider
this let expression from the last section:

let y = a*b
f x = (x+y)/y
in f c + f d

How does the parser know not to parse this as:

let y = a*b f
x = (x+y)/y
in f c + f d

?

The answer is that Haskell uses a two-dimensional syntax called
layout that essentially relies on declarations being "lined up in
columns." In the above example, note that y and f begin in the
same column. The rules for layout are spelled out in detail in the
Report (§1.5,§B.3), but in practice, use of
layout is rather intuitive. Just remember two things:

First, the next character following any of the keywords where,
let, or of is what determines the starting column for the
declarations in the where, let, or case expression being written (the
rule also applies to where used in the class and instance
declarations to be defined in Section 5). Thus
we can begin the declarations on the same line as the keyword, the
next line, etc. (The do keyword, to be discussed later, also uses layout).

Second, just be sure that the starting column is further to the right
than the starting column associated with the immediately surrounding
clause (otherwise it would be ambiguous). The "termination" of a
declaration happens when something appears at or to the left of the
starting column associated with that binding form. (Haskell
observes the convention that tabs count as 8 blanks; thus care must be
taken when using an editor which may observe some other convention.)

Layout is actually shorthand for an explicit grouping mechanism,
which deserves mention because it can be useful under certain
circumstances. The let example above is equivalent to:

let { y = a*b
; f x = (x+y)/y
}
in f c + f d

Note the explicit curly braces and semicolons. One way in which this
explicit notation is useful is when more than one declaration is
desired on a line; for example, this is a valid expression:

let y = a*b; z = a/b
f x = (x+y)/z
in f c + f d

For another example of the expansion of layout into explicit
delimiters, see §1.5.

The use of layout greatly reduces the syntactic clutter associated
with declaration lists, thus enhancing readability. It is easy to
learn, and its use is encouraged.