Extensible Pattern Matching via a Lightweight Language

New draft of a paper by the F# team: Extensible Pattern Matching via a Lightweight Language Extension

By Don Syme, Gregory Neverov, James Margetson

Abstract
Pattern matching of algebraic data types (ADTs) is a standard feature in typed functional programming languages but it is well known that it interacts poorly with abstraction. While several partial solutions to this problem have been proposed, few have been implemented or used. This paper describes an extension to the .NET language F# called active patterns, which supports pattern matching over abstract representations of generic heterogeneous data such as XML and term structures, including where these are represented via object models in other .NET languages. Our design is the first to incorporate both ad hoc pattern matching functions for partial decompositions and “views” for total decompositions, and yet remains a simple and lightweight extension. We give a description of the language extension along with numerous motivating examples. Finally we describe how this feature would interact with other reasonable and related language extensions: existential types quantified at data discrimination tags, GADTs, and monadic generalizations of pattern matching.

Don Syme's blog introduces the paper:

  • How we combine total, partial and parameterized active patterns in one unified mechanism
  • Examples of using active patterns to match on LazyLists, Complex numbers, .NET Objects, strings using Regular Expressions, XML data, Data structures and F# Quotation values.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

How come nobody had anything

How come nobody had anything to say about this paper (later published in ACM SIGPLAN Notices Volume 42 , Issue 9, September 2007)?

Maybe because it was pretty

Maybe because it was pretty straightforward. Seems like a pretty reasonable approach.

Though I didn't understand the point of the banana bracket notation. It looks like listing the cases is a clumsy way to refer to a pattern. Why not just have a 'pattern' construct that introduces a name for the pattern at the point where cases and defining function are specified?