Non-free data types are data types whose data have no canonical forms. For example, multisets are non-free data types because the multiset @math has two other equivalent but literally different forms @math and @math . Pattern matching is known to provide a handy tool set to treat such data types. Although many studies on pattern matching and implementations for practical programming languages have been proposed so far, we observe that none of these studies satisfy all the criteria of practical pattern matching, which are as follows: i) efficiency of the backtracking algorithm for non-linear patterns, ii) extensibility of matching process, and iii) polymorphism in patterns. This paper aims to design a new pattern-matching-oriented programming language that satisfies all the above three criteria. The proposed language features clean Scheme-like syntax and efficient and extensible pattern matching semantics. This programming language is especially useful for the processing of complex non-free data types that not only include multisets and sets but also graphs and symbolic mathematical expressions. We discuss the importance of our criteria of practical pattern matching and how our language design naturally arises from the criteria. The proposed language has been already implemented and open-sourced as the Egison programming language.
First-class patterns @cite_16 is a sophisticated system that treats patterns as first-class objects. The essence of this study is a that defines how to decompose data with each data constructor. First-class patterns can deal with pattern matching that generates multiple results. To generate multiple results, a pattern function returns a list. A critical limitation of this proposal is that first-class patterns do not support non-linear pattern matching.
@cite_16
2158107019
Pattern matching is a great convenience in programming. However, pattern matching has its problems: it conflicts with data abstraction; it is complex (at least in Haskell, which has pattern guards, irrefutable patterns, n+k patterns, as patterns, etc.); it is a source of runtime errors; and lastly, one cannot abstract over patterns as they are not a first class language construct. This paper proposes a simplification of pattern matching that makes patterns first class. The key idea is to treat patterns as functions of type "a Maybe b"--i.e., "a (Nothing|Just b)"; thus, patterns and pattern combinators can be written as functions in the language.