Pattern Matching with core.match

Pattern matching lets code branch on the shape of data rather than only on boolean tests. In Clojure, this is not a built-in core language feature in the same way it is in some ML-family languages, but libraries such as core.match make that style available when it materially improves clarity.

That last condition matters. Pattern matching is powerful, but it is not automatically clearer than cond, destructuring, multimethods, or explicit data dispatch. In Clojure, it should earn its place.

What Problem Pattern Matching Solves

Pattern matching is most useful when the code needs to branch on structured input:

• tagged vectors
• small AST nodes
• message formats
• nested tuple-like shapes
• recursive data with a few well-known variants

When the main question is “What shape of value do I have?” matching can be very expressive.

A Small Example

 1(ns app.expr
 2  (:require [clojure.core.match :refer [match]]))
 3
 4(defn eval-expr [expr]
 5  (match expr
 6    [:num n] n
 7    [:add a b] (+ (eval-expr a) (eval-expr b))
 8    [:mul a b] (* (eval-expr a) (eval-expr b))
 9    :else (throw (ex-info "Unknown expression"
10                          {:type ::unknown-expr
11                           :expr expr}))))

This is a good fit because the data shape is the main driver of behavior. The cases are compact and the branching logic stays close to the structure it is interpreting.

When core.match Helps

Use it when:

• destructuring alone becomes awkward
• nested shape checks are the central logic
• the set of input variants is relatively small and clear
• the matching cases are easier to read than layered cond or case

This often happens in interpreters, parsers, protocol adapters, and compiler-style transformations.

When It Does Not Help

Do not reach for pattern matching by default. Many Clojure problems are clearer with:

• plain map access
• case on one dispatch key
• multimethods for extensible data-based dispatch
• protocols when behavior belongs to types
• cond for straightforward predicate branching

If the match form is longer than the data logic it is trying to clarify, you are probably forcing it.

Pattern Matching And Data Design

Pattern matching works best when the data model is already clear. It should not be used to compensate for inconsistent or messy shapes. If some expressions are vectors, some are maps, and some are ad hoc lists with shifting positions, the real problem is the data model itself.

That makes this a design lesson as much as a syntax lesson: matching is easiest when the program uses stable tagged data.

Common Mistakes

The first mistake is using pattern matching for simple cases that a map lookup or case would express more directly.

The second mistake is treating core.match as if it were mandatory to write functional code. It is just one tool.

The third mistake is forgetting about extensibility. Pattern matching is often strongest when the set of variants is known and fairly closed. If the system should grow through open extension, multimethods may be a better fit.

Design Review Questions

Ask these when reviewing a pattern-matching design:

• Is the code primarily branching on data shape?
• Are the variants small, stable, and understandable?
• Would cond, case, or destructuring be simpler?
• Is the set of variants closed enough for local matching to stay maintainable?

Good pattern matching makes structured data easier to read. Bad pattern matching turns normal branching into ornamental syntax.