Pattern Matching: ML vs. Python

Hello! Welcome back to our course on programming theory.

In our last two lessons, we built a solid foundation by defining algebraic data types (ADTs)—first product types (records, tuples) and then sum types (variants, tagged unions). We saw that ADTs are a powerful way to model data. Today, we'll explore the mechanism that makes them so expressive and safe to use: pattern matching.

This lesson directly addresses the learning outcome: Use pattern matching for control flow and data extraction, comparing ML-style matching with Python's recent structural pattern matching.

We will dissect pattern matching into its two core functions: checking the shape of data and pulling values out of it. We'll start with the classic, type-safe style from the ML language family, and then dive into Python's powerful new match statement, analyzing how it adapts these functional ideas to a dynamic, object-oriented world.

1. The Essence of Pattern Matching: ML-Style

At its heart, pattern matching is a sophisticated conditional construct that combines two actions:

1. Control Flow: It checks a value against a series of "patterns" to see which one describes its structure. For a list, the patterns might be "is it empty?" or "does it have a head and a tail?". For a custom Tree type, it might be "is it an Empty tree, a Leaf, or an internal Node?".
2. Data Extraction: If a pattern matches, it simultaneously "de-structures" the value, binding its constituent parts to new variables that can be used in the corresponding block of code.

This combination of branching on structure and binding variables makes for incredibly clear and robust code, especially for recursive data structures. The ML language family (SML, OCaml, F#) and its descendants (Haskell, Scala) are the exemplars of this style.

Let's start by seeing how pattern matching works on lists, one of the most fundamental recursive data types.

The sum function is a canonical example of structural recursion, where the recursion follows the structure of the data type. Pattern matching is the natural syntax for expressing this, providing a case for each variant of the data type (the base case [] and the recursive case h::t).

Now, let's see how this applies to the custom ADTs we defined in previous lessons. Your reference text, Concepts in Programming Languages, uses Scala to illustrate this. Scala's case class is explicitly designed to bring ML-style ADTs and pattern matching into an object-oriented context.

The eval function is a classic use case. Without pattern matching, you would need a chain of if (e instanceof Number) checks and manual type casts, which is verbose and error-prone. Pattern matching makes the logic clean, safe, and declarative. A key feature in ML-family languages is exhaustiveness checking: the compiler will warn you if you forget to handle a case (e.g., if you added a Divide variant but forgot to update eval), preventing runtime errors.

2. Python's Structural Pattern Matching

Inspired by the power and clarity of ML-style matching, Python 3.10 introduced the match statement. It adapts these concepts to Python's dynamic, object-oriented nature. While it lacks the compile-time exhaustiveness checks of ML, it provides a similarly expressive tool for working with complex data structures.

Let's get a practical overview of its features.

As you can see, Python's match statement is a versatile tool. It can match on:

• Literals: case 42:, case "hello":
• Sequences: case [x, y]:, case [a, *rest]:
• Mappings (Dictionaries): case {"status": 200, "data": d}:
• Class Instances: case Point(x=x_val, y=y_val):

This brings a declarative, functional style directly into Python.

3. A Deeper Dive: Design and Comparison

To truly understand the comparison between ML-style and Python-style matching, it's valuable to look at the design principles behind Python's implementation. The feature was proposed and documented in a paper co-authored by Guido van Rossum.

Now, let's synthesize what we've learned into a direct comparison.

Feature	ML-Style (e.g., OCaml, Scala, Haskell)	Python-Style
Data Model	Matches on Algebraic Data Types (sum and product types). The structure is rigid and defined upfront.	Matches on Python's object model: sequences, mappings, and class instances. The structure is dynamic.
Type Safety	Static. The compiler verifies that patterns are well-typed and can check for exhaustiveness, warning if a variant of a sum type is not handled.	Dynamic. Type checks (isinstance) happen at runtime. No built-in compile-time exhaustiveness checking.
Deconstruction	Deconstructs ADT variants into their constituent parts. case Sum(l, r):	Deconstructs objects by checking their class and accessing attributes. case Sum(left=l, right=r):
Wildcard	_ matches anything without binding.	_ matches anything without binding.
Variable Binding	case Number(x): binds the contents of Number to x.	case Number(n=x): binds the n attribute's value to x.
Guards	Supported. case (x, y) if x > y => ...	Supported. case [x, y] if x > y:

Key Trade-Offs:

Your experience in designing complex systems at Revolut and now in EdTech highlights the constant tension between flexibility and correctness. Pattern matching is a microcosm of this trade-off.

• ML's Approach (Correctness-first): By tightly coupling pattern matching with statically-defined ADTs, ML-family languages provide powerful guarantees. The compiler becomes a partner in ensuring you've handled every possible state your data can be in. This is invaluable for building robust systems where unexpected states can have serious consequences (e.g., financial settlement).
• Python's Approach (Flexibility-first): Python's structural matching is designed to work with the existing, dynamic object model. You don't need to define special ADTs; you can match on any class or dictionary. This makes it incredibly useful for inspecting complex, heterogeneous data, like JSON from an API or events in a UI framework. The cost is the loss of compile-time safety; correctness is a runtime concern.

Conclusion

In this lesson, we've seen that pattern matching is a powerful control-flow and data extraction tool that originated in functional languages and has now been adopted by mainstream languages like Python.

Key Takeaways:

• Pattern matching serves two purposes: branching on the structure of data and extracting values from it.
• ML-style matching is tied to statically-defined Algebraic Data Types, enabling the compiler to perform exhaustiveness checking for high reliability.
• Python's structural pattern matching adapts these ideas to a dynamic context, matching on the structure of existing objects like sequences, mappings, and class instances.
• The fundamental trade-off is between the static safety of the ML approach and the dynamic flexibility of the Python approach.

Next Lesson Preview:

We now have all the pieces to build a complete, type-safe program in the functional style. In our next lesson, we will put our knowledge of ADTs and pattern matching into practice to tackle a classic problem: modeling and evaluating a simple mathematical expression language. This will solidify how these concepts work together to create programs that are both elegant and correct.