Does pattern matching require machine learning?

No. Many matchers are deterministic programs applying explicit patterns.

Can it handle nested data?

Yes. Structural and symbolic matching can inspect lists, trees, records or other supported structures.

Why can two matching systems disagree on the same-looking pattern?

Their syntax and semantics may differ, including wildcard meaning, capture rules, normalization and whether the entire input must match.

AI Glossary / Graphs and symbolic AI / Intermediate

Pattern matching

Definition

Pattern matching is the process of checking whether data fit a specified form and, where supported, extracting values from matching parts. In symbolic AI, patterns can contain constants, variables and structural relationships used to recognize facts or trigger rules.

What it means

A pattern is a description of what to look for. It can be a literal text fragment, a regular expression, a structured record template or a symbolic expression with placeholders. The matching rules determine which differences are allowed.

For example, a symbolic pattern Move(?item, A, B) could match Move(Box7, A, B), binding ?item to Box7. It would not match Move(Box7, B, A) because the specified positions differ.

This is distinct from learning a statistical pattern from examples. A matcher generally applies a supplied rule or pattern. It can be part of an AI system without itself learning, understanding natural language or deciding whether the matched data are factually true.

How it works

A matcher compares a pattern with an input according to defined syntax and semantics. Literal components must agree. Variable components can bind to values, and structured components require compatible shapes and recursively matching parts.

In a symbolic matcher with consistent repeated-variable bindings, Pair(?x,?x) matches Pair(red,red) but fails on Pair(red,blue). Not every programming language uses that exact notation or permits repeated capture names, so the convention must be explicit.

Some systems support alternatives, sequence segments, wildcards or guards that test extra conditions. Multiple matches may exist, requiring a rule for selecting or enumerating them. Rule engines can use resulting bindings to instantiate an action or conclusion.

Unification is closely related but can solve for variables on both sides of an expression comparison. Ordinary one-sided matching treats the input as fixed and resolves variables in the pattern. Specialized formalisms use more detailed distinctions.

Three practical examples

A rule engine matches an order record against a template before evaluating an additional quantity condition.
A compiler recognizes a particular expression-tree shape to apply a justified rewrite.
A document utility extracts identifiers that satisfy a specified text pattern, then validates them separately against authoritative records.

Think of it this way

Think of a stencil with fixed shapes and labeled openings. Data fit when the fixed parts align, and the openings reveal values to collect.

The analogy is limited because symbolic patterns can be nested, contain repeated-variable constraints or use logical guards. A matching shape also does not prove meaning. An identifier can fit a format while referring to no real item, just as a shape fitting a stencil does not establish its origin.

Worked example

Use an invented symbolic pattern Transfer(?item, ?site, ?site), where repeated variables must have the same binding. Compare three inputs:

Transfer(Crate4, DepotA, DepotA) matches with ?item=Crate4 and ?site=DepotA. Transfer(Crate4, DepotA, DepotB) fails because ?site would need two different values. Transfer(Crate4, DepotA) fails because the expression has the wrong number of arguments.

Now change the pattern to Transfer(?item, ?from, ?to) and add the guard ?from≠?to. The DepotA-to-DepotB input passes both structural matching and the guard. The DepotA-to-DepotA input matches structurally but fails the guard.

This example separates matching, variable consistency, arity and an additional condition. It makes no claim that any transfer actually occurred or that it was authorized. The notation is illustrative, not executable syntax for a named programming language.

Illustrative case study

The fictional Maple Records team uses a text pattern to identify equipment codes in incoming messages. Initially, it treats every format match as a valid equipment reference.

A review finds well-formed but nonexistent codes. Maple separates extraction from lookup and records whether the identifier merely matched the syntax or was confirmed against the equipment register. It also tests case handling and punctuation rather than assuming all input variations are equivalent.

The fictional lesson is that recognition of a form is one stage in a workflow. Semantic validation and any resulting decision need their own rules and evidence.

Common misconceptions and mistakes

A match proves the input is true. It establishes conformity to a pattern, not factual accuracy.
Pattern matching is always regular-expression matching. Structured symbolic and programming-language patterns are different forms.
Matching and unification are identical in every context. One-sided binding and two-sided variable resolution differ.
A variable can silently mean different values at each occurrence. In many symbolic matchers, repeated bindings must remain consistent.
A broader pattern is always better. It may accept unintended cases and trigger unsuitable rules.

Business use

Pattern matching is useful for predictable formats, interpretable rules and structured data handling. It can simplify extraction or dispatch when the accepted forms are well defined.

Specify the pattern language, normalization, match scope and failure behavior. Decide whether matching covers an entire input or only a substring, whether several matches are returned, and how ambiguous rules are prioritized.

Evaluate both accepted and rejected examples, including near-matches. Keep structural recognition separate from business validation and consequential actions. A rule that extracts an order number should not automatically establish that the order exists, belongs to the current customer or permits an update.

Check your understanding

Why does Transfer(Crate4,DepotA,DepotB) fail the pattern Transfer(?item,?site,?site) in the worked example?

Answer: The same pattern variable ?site occurs twice and must retain one value. DepotA and DepotB differ, so no consistent binding satisfies both positions.

Related terms

Unification
Regular expression
Symbolic AI
variable binding
structural matching
rule engine
guard condition
term rewriting

Learn next

Write a structured pattern with one repeated variable and test a match, a value conflict and a wrong-shape input. Then add a guard and distinguish structural success from guard success. Check the exact rules before translating the example into a real programming language.

Sources

Norvig's pattern-matching utility illustrates variables, bindings and richer symbolic patterns: https://github.com/norvig/paip-lisp/blob/main/lisp/patmatch.lisp

Norvig's accompanying chapter explains the matching tool: https://github.com/norvig/paip-lisp/blob/main/docs/chapter6.md

Python's language reference provides a distinct structural-matching specification: https://docs.python.org/3/reference/compound_stmts.html#the-match-statement

The transfer notation and Maple Records case are original examples; they are not Python pattern syntax.

Previous: Pattern grammar Next: Pattern recognition