Pattern matching is ubiquitous in F#. It is used for binding values to expressions with `let`

, and in function parameters, and for branching using the `match..with`

syntax.

We have briefly covered binding values to expressions in a post in the “why use F#?” series, and it will be covered many times as we investigate types.

So in this post, we’ll cover the `match..with`

syntax and its use for control flow.

We have already seen `match..with`

expressions a number of times. And we know that it has the form:

```
match [something] with
| pattern1 -> expression1
| pattern2 -> expression2
| pattern3 -> expression3
```

If you squint at it just right, it looks a bit like a series of lambda expressions:

```
match [something] with
| lambda-expression-1
| lambda-expression-2
| lambda-expression-3
```

Where each lambda expression has exactly one parameter:

```
param -> expression
```

So one way of thinking about `match..with`

is that it is a choice between a set of lambda expressions. But how to make the choice?

This is where the patterns come in. The choice is made based on whether the “match with” value can be matched with the parameter of the lambda expression. The first lambda whose parameter can be made to match the input value “wins”!

So for example, if the param is the wildcard `_`

, it will always match, and if first, always win.

```
_ -> expression
```

Looking at the following example:

```
let x =
match 1 with
| 1 -> "a"
| 2 -> "b"
| _ -> "z"
```

We can see that there are three lambda expressions to match, in this order:

```
fun 1 -> "a"
fun 2 -> "b"
fun _ -> "z"
```

So, the `1`

pattern gets tried first, then then the `2`

pattern, and finally, the `_`

pattern.

On the other hand, if we changed the order to put the wildcard first, it would be tried first and always win immediately:

```
let x =
match 1 with
| _ -> "z"
| 1 -> "a"
| 2 -> "b"
```

In this case, the F# compiler helpfully warns us that the other rules will never be matched.

So this is one major difference between a “`switch`

” or “`case`

” statement compared with a `match..with`

. In a `match..with`

, **the order is important**.

Since F# is sensitive to indentation, you might be wondering how best to format this expression, as there are quite a few moving parts.

The post on F# syntax gives an overview of how alignment works, but for `match..with`

expressions, here are some specific guidelines.

**Guideline 1: The alignment of the | expression clauses should be directly under the match**

This guideline is straightforward.

```
let f x = match x with
// aligned
| 1 -> "pattern 1"
// aligned
| 2 -> "pattern 2"
// aligned
| _ -> "anything"
```

**Guideline 2: The match..with should be on a new line**

The `match..with`

can be on the same line or a new line, but using a new line keeps the indenting consistent, independent of the lengths of the names:

```
// ugly alignment!
let myVeryLongNameForAFunction myParameter = match myParameter with
| 1 -> "something"
| _ -> "anything"
// much better
let myVeryLongNameForAFunction myParameter =
match myParameter with
| 1 -> "something"
| _ -> "anything"
```

**Guideline 3: The expression after the arrow -> should be on a new line**

Again, the result expression can be on the same line as the arrow, but using a new line again keeps the indenting consistent and helps to separate the match pattern from the result expression.

```
let f x =
match x with
| "a very long pattern that breaks up the flow" -> "something"
| _ -> "anything"
let f x =
match x with
| "a very long pattern that breaks up the flow" ->
"something"
| _ ->
"anything"
```

Of course, when all the patterns are very compact, a common sense exception can be made:

```
let f list =
match list with
| [] -> "something"
| x::xs -> "something else"
```

It is important to realize that `match..with`

is not really a “control flow” construct. The “control” does not “flow” down the branches, but instead, the whole thing is an expression that gets evaluated at some point, just like any other expression. The end result in practice might be the same, but it is a conceptual difference that can be important.

One consequence of it being an expression is that all branches *must* evaluate to the *same* type – we have already seen this same behavior with if-then-else expressions and for loops.

```
let x =
match 1 with
| 1 -> 42
| 2 -> true // error wrong type
| _ -> "hello" // error wrong type
```

You cannot mix and match the types in the expression.

Since they are normal expressions, match expressions can appear anywhere an expression can be used.

For example, here’s a nested match expression:

```
// nested match..withs are ok
let f aValue =
match aValue with
| x ->
match x with
| _ -> "something"
```

And here’s a match expression embedded in a lambda:

```
[2..10]
|> List.map (fun i ->
match i with
| 2 | 3 | 5 | 7 -> sprintf "%i is prime" i
| _ -> sprintf "%i is not prime" i
)
```

Another consequence of being an expression is that there must always be *some* branch that matches. The expression as a whole must evaluate to *something*!

That is, the valuable concept of “exhaustive matching” comes from the “everything-is-an-expression” nature of F#. In a statement oriented language, there would be no requirement for this to happen.

Here’s an example of an incomplete match:

```
let x =
match 42 with
| 1 -> "a"
| 2 -> "b"
```

The compiler will warn you if it thinks there is a missing branch.
And if you deliberately ignore the warning, then you will get a nasty runtime error (`MatchFailureException`

) when none of the patterns match.

The algorithm for checking that all possible matches are listed is good but not always perfect. Occasionally it will complain that you have not matched every possible case, when you know that you have. In this case, you may need to add an extra case just to keep the compiler happy.

One way to guarantee that you always match all cases is to put the wildcard parameter as the last match:

```
let x =
match 42 with
| 1 -> "a"
| 2 -> "b"
| _ -> "z"
```

You see this pattern frequently, and I have used it a lot in these examples. It’s the equivalent of having a catch-all `default`

in a switch statement.

But if you want to get the full benefits of exhaustive pattern matching, I would encourage you *not* to use wildcards,
and try to match all the cases explicitly if you can. This is particularly true if you are matching on
the cases of a union type:

```
type Choices = A | B | C
let x =
match A with
| A -> "a"
| B -> "b"
| C -> "c"
//NO default match
```

By being always explicit in this way, you can trap any error caused by adding a new case to the union. If you had a wildcard match, you would never know.

If you can’t have *every* case be explicit, you might try to document your boundary conditions as much as possible, and assert an runtime error for the wildcard case.

```
let x =
match -1 with
| 1 -> "a"
| 2 -> "b"
| i when i >= 0 && i<=100 -> "ok"
// the last case will always match
| x -> failwithf "%i is out of range" x
```

There are lots of different ways of matching patterns, which we’ll look at next.

For more details on the various patterns, see the MSDN documentation.

The most basic pattern is to bind to a value as part of the match:

```
let y =
match (1,0) with
// binding to a named value
| (1,x) -> printfn "x=%A" x
```

*By the way, I have deliberately left this pattern (and others in this post) as incomplete. As an exercise, make them complete without using the wildcard.*

It is important to note that the values that are bound *must* be distinct for each pattern. So you can’t do something like this:

```
let elementsAreEqual aTuple =
match aTuple with
| (x,x) ->
printfn "both parts are the same"
| (_,_) ->
printfn "both parts are different"
```

Instead, you have to do something like this:

```
let elementsAreEqual aTuple =
match aTuple with
| (x,y) ->
if (x=y) then printfn "both parts are the same"
else printfn "both parts are different"
```

This second option can also be rewritten using “guards” (`when`

clauses) instead. Guards will be discussed shortly.

You can combine multiple patterns on one line, with OR logic and AND logic:

```
let y =
match (1,0) with
// OR -- same as multiple cases on one line
| (2,x) | (3,x) | (4,x) -> printfn "x=%A" x
// AND -- must match both patterns at once
// Note only a single "&" is used
| (2,x) & (_,1) -> printfn "x=%A" x
```

The OR logic is particularly common when matching a large number of union cases:

```
type Choices = A | B | C | D
let x =
match A with
| A | B | C -> "a or b or c"
| D -> "d"
```

Lists can be matched explicitly in the form `[x;y;z]`

or in the “cons” form `head::tail`

:

```
let y =
match [1;2;3] with
// binding to explicit positions
// square brackets used!
| [1;x;y] -> printfn "x=%A y=%A" x y
// binding to head::tail.
// no square brackets used!
| 1::tail -> printfn "tail=%A" tail
// empty list
| [] -> printfn "empty"
```

A similar syntax is available for matching arrays exactly `[|x;y;z|]`

.

It is important to understand that sequences (aka `IEnumerables`

) can *not* be matched on this way directly, because they are “lazy” and meant to be accessed one element at a time.
Lists and arrays, on the other hand, are fully available to be matched on.

Of these patterns, the most common one is the “cons” pattern, often used in conjunction with recursion to loop through the elements of the list.

Here are some examples of looping through lists using recursion:

```
// loop through a list and print the values
let rec loopAndPrint aList =
match aList with
// empty list means we're done.
| [] ->
printfn "empty"
// binding to head::tail.
| x::xs ->
printfn "element=%A," x
// do all over again with the
// rest of the list
loopAndPrint xs
//test
loopAndPrint [1..5]
// ------------------------
// loop through a list and sum the values
let rec loopAndSum aList sumSoFar =
match aList with
// empty list means we're done.
| [] ->
sumSoFar
// binding to head::tail.
| x::xs ->
let newSumSoFar = sumSoFar + x
// do all over again with the
// rest of the list and the new sum
loopAndSum xs newSumSoFar
//test
loopAndSum [1..5] 0
```

The second example shows how we can carry state from one iteration of the loop to the next using a special “accumulator” parameter (called `sumSoFar`

in this example). This is a very common pattern.

Pattern matching is available for all the built-in F# types. More details in the series on types.

```
// -----------------------
// Tuple pattern matching
let aTuple = (1,2)
match aTuple with
| (1,_) -> printfn "first part is 1"
| (_,2) -> printfn "second part is 2"
// -----------------------
// Record pattern matching
type Person = {First:string; Last:string}
let person = {First="john"; Last="doe"}
match person with
| {First="john"} -> printfn "Matched John"
| _ -> printfn "Not John"
// -----------------------
// Union pattern matching
type IntOrBool= I of int | B of bool
let intOrBool = I 42
match intOrBool with
| I i -> printfn "Int=%i" i
| B b -> printfn "Bool=%b" b
```

Sometimes you want to match the individual components of the value *and* also the whole thing. You can use the `as`

keyword for this.

```
let y =
match (1,0) with
// binding to three values
| (x,y) as t ->
printfn "x=%A and y=%A" x y
printfn "The whole tuple is %A" t
```

You can match on subtypes, using the `:?`

operator, which gives you a crude polymorphism:

```
let x = new Object()
let y =
match x with
| :? System.Int32 ->
printfn "matched an int"
| :? System.DateTime ->
printfn "matched a datetime"
| _ ->
printfn "another type"
```

This only works to find subclasses of a parent class (in this case, Object). The overall type of the expression has the parent class as input.

Note that in some cases, you may need to “box” the value.

```
let detectType v =
match v with
| :? int -> printfn "this is an int"
| _ -> printfn "something else"
// error FS0008: This runtime coercion or type test from type 'a to int
// involves an indeterminate type based on information prior to this program point.
// Runtime type tests are not allowed on some types. Further type annotations are needed.
```

The message tells you the problem: “runtime type tests are not allowed on some types”. The answer is to “box” the value which forces it into a reference type, and then you can type check it:

```
let detectTypeBoxed v =
match box v with // used "box v"
| :? int -> printfn "this is an int"
| _ -> printfn "something else"
//test
detectTypeBoxed 1
detectTypeBoxed 3.14
```

In my opinion, matching and dispatching on types is a code smell, just as it is in object-oriented programming. It is occasionally necessary, but used carelessly is an indication of poor design.

In a good object oriented design, the correct approach would be to use polymorphism to replace the subtype tests, along with techniques such as double dispatch. So if you are doing this kind of OO in F#, you should probably use those same techniques.

All the patterns we’ve looked at so far do pattern matching on a *single* value. How can you do it for two or more?

The short answer is: you can’t. Matches are only allowed on single values.

But wait a minute – could we combine two values into a *single* tuple on the fly and match on that? Yes, we can!

```
let matchOnTwoParameters x y =
match (x,y) with
| (1,y) ->
printfn "x=1 and y=%A" y
| (x,1) ->
printfn "x=%A and y=1" x
```

And indeed, this trick will work whenever you want to match on a set of values – just group them all into a single tuple.

```
let matchOnTwoTuples x y =
match (x,y) with
| (1,_),(1,_) -> "both start with 1"
| (_,2),(_,2) -> "both end with 2"
| _ -> "something else"
// test
matchOnTwoTuples (1,3) (1,2)
matchOnTwoTuples (3,2) (1,2)
```

Sometimes pattern matching is just not enough, as we saw in this example:

```
let elementsAreEqual aTuple =
match aTuple with
| (x,y) ->
if (x=y) then printfn "both parts are the same"
else printfn "both parts are different"
```

Pattern matching is based on patterns only – it can’t use functions or other kinds of conditional tests.

But there *is* a way to do the equality test as part of the pattern match – using an additional `when`

clause to the left of the function arrow.
These clauses are known as “guards”.

Here’s the same logic written using a guard instead:

```
let elementsAreEqual aTuple =
match aTuple with
| (x,y) when x=y ->
printfn "both parts are the same"
| _ ->
printfn "both parts are different"
```

This is nicer, because we have integrated the test into the pattern proper, rather than using a test after the match has been done.

Guards can be used for all sorts of things that pure patterns can’t be used for, such as:

- comparing the bound values
- testing object properties
- doing other kinds of matching, such as regular expressions
- conditionals derived from functions

Let’s look at some examples of these:

```
// --------------------------------
// comparing values in a when clause
let makeOrdered aTuple =
match aTuple with
// swap if x is bigger than y
| (x,y) when x > y -> (y,x)
// otherwise leave alone
| _ -> aTuple
//test
makeOrdered (1,2)
makeOrdered (2,1)
// --------------------------------
// testing properties in a when clause
let isAM aDate =
match aDate:System.DateTime with
| x when x.Hour <= 12->
printfn "AM"
// otherwise leave alone
| _ ->
printfn "PM"
//test
isAM System.DateTime.Now
// --------------------------------
// pattern matching using regular expressions
open System.Text.RegularExpressions
let classifyString aString =
match aString with
| x when Regex.Match(x,@".+@.+").Success->
printfn "%s is an email" aString
// otherwise leave alone
| _ ->
printfn "%s is something else" aString
//test
classifyString "alice@example.com"
classifyString "google.com"
// --------------------------------
// pattern matching using arbitrary conditionals
let fizzBuzz x =
match x with
| i when i % 15 = 0 ->
printfn "fizzbuzz"
| i when i % 3 = 0 ->
printfn "fizz"
| i when i % 5 = 0 ->
printfn "buzz"
| i ->
printfn "%i" i
//test
[1..30] |> List.iter fizzBuzz
```

Guards are great for one-off matches. But if there are certain guards that you use over and over, consider using active patterns instead.

For example, the email example above could be rewritten as follows:

```
open System.Text.RegularExpressions
// create an active pattern to match an email address
let (|EmailAddress|_|) input =
let m = Regex.Match(input,@".+@.+")
if (m.Success) then Some input else None
// use the active pattern in the match
let classifyString aString =
match aString with
| EmailAddress x ->
printfn "%s is an email" x
// otherwise leave alone
| _ ->
printfn "%s is something else" aString
//test
classifyString "alice@example.com"
classifyString "google.com"
```

You can see other examples of active patterns in a previous post.

In the examples so far, we’ve seen a lot of this:

```
let f aValue =
match aValue with
| _ -> "something"
```

In the special case of function definitions we can simplify this dramatically by using the `function`

keyword.

```
let f =
function
| _ -> "something"
```

As you can see, the `aValue`

parameter has completely disappeared, along with the `match..with`

.

This keyword is *not* the same as the `fun`

keyword for standard lambdas, rather it combines `fun`

and `match..with`

in a single step.

The `function`

keyword works anywhere a function definition or lambda can be used, such as nested matches:

```
// using match..with
let f aValue =
match aValue with
| x ->
match x with
| _ -> "something"
// using function keyword
let f =
function
| x ->
function
| _ -> "something"
```

or lambdas passed to a higher order function:

```
// using match..with
[2..10] |> List.map (fun i ->
match i with
| 2 | 3 | 5 | 7 -> sprintf "%i is prime" i
| _ -> sprintf "%i is not prime" i
)
// using function keyword
[2..10] |> List.map (function
| 2 | 3 | 5 | 7 -> sprintf "prime"
| _ -> sprintf "not prime"
)
```

A minor drawback of `function`

compared with `match..with`

is that you can’t see the original input value and have to rely on value bindings in the pattern.

In the previous post, we looked at catching exceptions with the `try..with`

expression.

```
try
failwith "fail"
with
| Failure msg -> "caught: " + msg
| :? System.InvalidOperationException as ex -> "unexpected"
```

The `try..with`

expression implements pattern matching in the same way as `match..with`

.

So in the above example we see the use of matching on a custom pattern

`| Failure msg`

is an example of matching on (what looks like) an active pattern`| :? System.InvalidOperationException as ex`

is an example of matching on the subtype (with the use of`as`

as well).

Because the `try..with`

expression implements full pattern matching, we can also use guards as well, if needed to add extra conditional logic:

```
let debugMode = false
try
failwith "fail"
with
| Failure msg when debugMode ->
reraise()
| Failure msg when not debugMode ->
printfn "silently logged in production: %s" msg
```

Match expressions are very useful, but can lead to complex code if not used carefully.

The main problem is that match expressions doesn’t compose very well. That is, it is hard to chain `match..with`

expressions and build simple ones into complex ones.

The best way of avoiding this is to wrap `match..with`

expressions into functions, which can then be composed nicely.

Here’s a simple example. The `match x with 42`

is wrapped in a `isAnswerToEverything`

function.

```
let times6 x = x * 6
let isAnswerToEverything x =
match x with
| 42 -> (x,true)
| _ -> (x,false)
// the function can be used for chaining or composition
[1..10] |> List.map (times6 >> isAnswerToEverything)
```

Most built-in F# types have such functions already available.

For example, instead of using recursion to loop through lists, you should try to use the functions in the `List`

module, which will do almost everything you need.

In particular, the function we wrote earlier:

```
let rec loopAndSum aList sumSoFar =
match aList with
| [] ->
sumSoFar
| x::xs ->
let newSumSoFar = sumSoFar + x
loopAndSum xs newSumSoFar
```

can be rewritten using the `List`

module in at least three different ways!

```
// simplest
let loopAndSum1 aList = List.sum aList
[1..10] |> loopAndSum1
// reduce is very powerful
let loopAndSum2 aList = List.reduce (+) aList
[1..10] |> loopAndSum2
// fold is most powerful of all
let loopAndSum3 aList = List.fold (fun sum i -> sum+i) 0 aList
[1..10] |> loopAndSum3
```

Similarly, the Option type (discussed at length in this post) has an associated `Option`

module with many useful functions.

For example, a function that does a match on `Some`

vs `None`

can be replaced with `Option.map`

:

```
// unnecessary to implement this explicitly
let addOneIfValid optionalInt =
match optionalInt with
| Some i -> Some (i + 1)
| None -> None
Some 42 |> addOneIfValid
// much easier to use the built in function
let addOneIfValid2 optionalInt =
optionalInt |> Option.map (fun i->i+1)
Some 42 |> addOneIfValid2
```

Finally, if you create your own types which need to be frequently matched, it is good practice to create a corresponding generic “fold” function that wraps it nicely.

For example, here is a type for defining temperature.

```
type TemperatureType = F of float | C of float
```

Chances are, we will matching these cases a lot, so let’s create a generic function that will do the matching for us.

```
module Temperature =
let fold fahrenheitFunction celsiusFunction aTemp =
match aTemp with
| F f -> fahrenheitFunction f
| C c -> celsiusFunction c
```

All `fold`

functions follow this same general pattern:

- there is one function for each case in the union structure (or clause in the match pattern)
- finally, the actual value to match on comes last. (Why? See the post on “designing functions for partial application”)

Now we have our fold function, we can use it in different contexts.

Let’s start by testing for a fever. We need a function for testing degrees F for fever and another one for testing degrees C for fever.

And then we combine them both using the fold function.

```
let fFever tempF =
if tempF > 100.0 then "Fever!" else "OK"
let cFever tempC =
if tempC > 38.0 then "Fever!" else "OK"
// combine using the fold
let isFever aTemp = Temperature.fold fFever cFever aTemp
```

And now we can test.

```
let normalTemp = C 37.0
let result1 = isFever normalTemp
let highTemp = F 103.1
let result2 = isFever highTemp
```

For a completely different use, let’s write a temperature conversion utility.

Again we start by writing the functions for each case, and then combine them.

```
let fConversion tempF =
let convertedValue = (tempF - 32.0) / 1.8
TemperatureType.C convertedValue //wrapped in type
let cConversion tempC =
let convertedValue = (tempC * 1.8) + 32.0
TemperatureType.F convertedValue //wrapped in type
// combine using the fold
let convert aTemp = Temperature.fold fConversion cConversion aTemp
```

Note that the conversion functions wrap the converted values in a new `TemperatureType`

, so the `convert`

function has the signature:

```
val convert : TemperatureType -> TemperatureType
```

And now we can test.

```
let c20 = C 20.0
let resultInF = convert c20
let f75 = F 75.0
let resultInC = convert f75
```

We can even call convert twice in a row, and we should get back the same temperature that we started with!

```
let resultInC = C 20.0 |> convert |> convert
```

There will be much more discussion on folds in the upcoming series on recursion and recursive types.