Explaining pattern matching vs switch

Question

I have been trying to explain the difference between switch statements and pattern matching(F#) to a couple of people but I haven't really been able to explain it well..most of the time they just look at me and say "so why don't you just use if..then..else".

How would you explain it to them?

Answer 1

If-Else (or switch) statements are about choosing different ways to process a value (input) depending on properties of the value at hand.

Pattern matching is about defining how to process a value given its structure, (also note that single case pattern matches make sense).

Thus pattern matching is more about deconstructing values than making choices, this makes them a very convenient mechanism for defining (recursive) functions on inductive structures (recursive union types), which explains why they are so abundantly used in languages like Ocaml etc.

PS: You might know the pattern-match and If-Else "patterns" from their ad-hoc use in math;

"if x has property A then y else z" (If-Else)

"some term in p1..pn where .... is the prime decomposition of x.." ((single case) pattern match)

Answer 2

Patterns give you a small language to describe the structure of the values you want to match. The structure can be arbitrarily deep and you can bind variables to parts of the structured value.

This allows you to write things extremely succinctly. You can illustrate this with a small example, such as a derivative function for a simple type of mathematical expressions:

type expr =
    | Int of int
    | Var of string
    | Add of expr * expr
    | Mul of expr * expr;;

let rec d(f, x) =
    match f with
    | Var y when x=y -> Int 1
    | Int _ | Var _ -> Int 0
    | Add(f, g) -> Add(d(f, x), d(g, x))
    | Mul(f, g) -> Add(Mul(f, d(g, x)), Mul(g, d(f, x)));;

Additionally, because pattern matching is a static construct for static types, the compiler can (i) verify that you covered all cases (ii) detect redundant branches that can never match any value (iii) provide a very efficient implementation (with jumps etc.).

Answer 3

Tuples have "," and Variants have Ctor args .. these are constructors, they create things.

Patterns are destructors, they rip them apart.

They're dual concepts.

To put this more forcefully: the notion of a tuple or variant cannot be described merely by its constructor: the destructor is required or the value you made is useless. It is these dual descriptions which define a value.

Generally we think of constructors as data, and destructors as control flow. Variant destructors are alternate branches (one of many), tuple destructors are parallel threads (all of many).

The parallelism is evident in operations like

(f * g) . (h * k) = (f . h * g . k) 

if you think of control flowing through a function, tuples provide a way to split up a calculation into parallel threads of control.

Looked at this way, expressions are ways to compose tuples and variants to make complicated data structures (think of an AST).

And pattern matches are ways to compose the destructors (again, think of an AST).

Answer 4

Excerpt from this blog article:

Pattern matching has several advantages over switch statements and method dispatch:

• Pattern matches can act upon ints, floats, strings and other types as well as objects.
• Pattern matches can act upon several different values simultaneously: parallel pattern matching. Method dispatch and switch are limited to a single value, e.g. "this".
• Patterns can be nested, allowing dispatch over trees of arbitrary depth. Method dispatch and switch are limited to the non-nested case.
• Or-patterns allow subpatterns to be shared. Method dispatch only allows sharing when methods are from classes that happen to share a base class. Otherwise you must manually factor out the commonality into a separate function (giving it a name) and then manually insert calls from all appropriate places to your unnecessary function.
• Pattern matching provides redundancy checking which catches errors.
• Nested and/or parallel pattern matches are optimized for you by the F# compiler. The OO equivalent must be written by hand and constantly reoptimized by hand during development, which is prohibitively tedious and error prone so production-quality OO code tends to be extremely slow in comparison.
• Active patterns allow you to inject custom dispatch semantics.

Answer 5

Pattern matches in OCaml, in addition to being more expressive as mentioned in several ways that have been described above, also give some very important static guarantees. The compiler will prove for you that the case-analysis embodied by your pattern-match statement is:

• exhaustive (no cases are missed)
• non-redundant (no cases that can never be hit because they are pre-empted by a previous case)
• sound (no patterns that are impossible given the datatype in question)

This is a really big deal. It's helpful when you're writing the program for the first time, and enormously useful when your program is evolving. Used properly, match-statements make it easier to change the types in your code reliably, because the type system points you at the broken match statements, which are a decent indicator of where you have code that needs to be fixed.

Answer 6

Switch is the two front wheels.

Pattern-matching is the entire car.

Answer 7

Off the top of my head:

1. The compiler can tell if you haven't covered all possibilities in your matches
2. You can use a match as an assignment
3. If you have a discriminated union, each match can have a different 'type'

Answer 8

Having formerly been one of "those people", I don't know that there's a succinct way to sum up why pattern-matching is such tasty goodness. It's experiential.

Back when I had just glanced at pattern-matching and thought it was a glorified switch statement, I think that I didn't have experience programming with algebraic data types (tuples and discriminated unions) and didn't quite see that pattern matching was both a control construct and a binding construct. Now that I've been programming with F#, I finally "get it". Pattern-matching's coolness is due to a confluence of features found in functional programming languages, and so it's non-trivial for the outsider-looking-in to appreciate.

I tried to sum up one aspect of why pattern-matching is useful in the second of a short two-part blog series on language and API design; check out part one and part two.

Answer 9

Perhaps you could draw an analogy with strings and regular expressions? You describe what you are looking for, and let the compiler figure out how for itself. It makes your code much simpler and clearer.

As an aside: I find that the most useful thing about pattern matching is that it encourages good habits. I deal with the corner cases first, and it's easy to check that I've covered every case.