Not to be reproduced

. Active patterns apply preprocessing functions to data type values before they are matched. This is of use for unfree data types where more than one representation exists for an abstract value: in many cases there is a specific representation for which function definitions become very simple, and active patterns just allow to assume this specific representation in function definitions. We define the semantics of active patterns and describe their implementation. 1 Introduction Pattern matching is a well-appreciated concept of (functional) programming. It contributes to concise function definitions by implicitly decomposing data type values. In many cases, a large part of a function's definition is only needed to prepare for recursive application and to finally lead to a base case for which the definition itself is rather simple. Such function definitions could be simplified considerably if these preparatory computations could be factorized and given in a separate place. Recognizing t...

Abstract. Many algorithms use concrete data types with some additional invariants. The set of values satisfying the invariants is often a set of representatives for the equivalence classes of some equational theory. For instance, a sorted list is a particular representative wrt commutativity. Theories like associativity, neutral element, idempotence, etc. are also very common. Now, when one wants to combine various invariants, it may be difficult to find the suitable representatives and to efficiently implement the invariants. The preservation of invariants throughout the whole program is even more difficult and error prone. Classically, the programmer solves this problem using a combination of two techniques: the definition of appropriate construction functions for the representatives and the consistent usage of these functions ensured via compiler data type for the representatives; unfortunately, pattern matching on representatives is lost. A more appealing alternative is to define a concrete data type with private constructors so that both compiler verification and pattern matching on representatives are granted. In this paper, we detail the notion of private data type and study the existence of construction functions. We also describe a prototype, called Moca, that addresses the entire problem of defining concrete data types with invariants: it generates efficient construction functions for the combination of common invariants and builds representatives that belong to a concrete data type with private constructors. 1

We propose three extensions to patterns and pattern matching in Haskell. The first, pattern guards, allows the guards of a guarded equation to match patterns and bind variables, as well as to test boolean condition. For this we introduce a natural generalisation of guard expressions to guard qualifiers. A frequently-occurring special case is that a function should be applied to a matched value, and the result of this is to be matched against another pattern. For this we introduce a syntactic abbreviation, transformational patterns, that is particularly useful when dealing with views. These proposals can be implemented with very modest syntactic and implementation cost. They are upward compatible with Haskell; all existing programs will continue to work. We also offer a third, much more speculative proposal, which provides the transformational-pattern construct with additional power to explicitly catch pattern match failure. We demonstrate the usefulness of the proposed extension by several examples, in particular, we compare our proposal with views, and we also discuss the use of the new patterns in combination with equational reasoning.

Abstract. Pattern matching is advantageous for understanding and reasoning about function definitions, but it tends to tightly couple the interface and implementation of a datatype. Significant effort has been invested in tackling this loss of modularity; however, decoupling patterns from concrete representations while maintaining soundness of reasoning has been a challenge. Inspired by the development of invertible programming, we propose an approach to abstract datatypes based on a rightinvertible language rinv—every function has a right (or pre-) inverse. We show how this new design is able to permit a smooth incremental transition from programs with algebraic datatypes and pattern matching, to ones with proper encapsulation (implemented as abstract datatypes), while maintaining simple and sound reasoning.

Abstract. We introduce a class of deterministic higher-order patterns to Template Haskell for supporting declarative transformational programming with more elegant binding of pattern variables. Higher-order patterns are capable of checking and binding subtrees far from the root, which is useful for program manipulation. However, there are three major problems. First, it is difficult to explain why a particular desired matching result cannot be obtained because of the complicated higherorder matching algorithm. Second, the general higher-order matching algorithm is of high cost, which may be exponential time at worst. Third, the (possibly infinite) nondeterministic solutions of higher-order matching prevents it from being used in a functional setting. To resolve these problems, we impose reasonable restrictions on higher-order patterns to gain predictability, efficiency and determinism. We show that our deterministic higher-order patterns are powerful to support concise specification and efficient implementation of various kinds of program transformations for optimizations. 1