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.

We take the term X/O impedance mismatch to describe the difficulty of the OO paradigm to accommodate XML processing by means of recasting it to typed OO programming. In particular, given XML types (say, XML schemas), it is notoriously difficult to map them automatically to object types (say, object models) that (i) reasonably compare to native object types typically devised by OO developers; (ii) fully preserve the intent of the original XML types; (iii) fully support round-tripping of arbitrary, valid XML data; and (iv) provide a general and convenient programming model for XML data hosted by objects. We reveal the X/O impedance mismatch in particular detail. That is, we survey the relevant differences between XML and objects in terms of their data models and their type systems. In this process, we systematically record and assess Xto-O mapping options. Our illustrations employ XSD (1.0) as the XML-schema language of choice and C# (1.0–3.0) as the bound of OO language expressiveness.

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.

Parallel pattern-matching offers the maximum laziness for programs written in lazy functional languages. Function arguments are evaluated concurrently and all arguments are given equal precedence, so functions can return results whenever possible in the presence of errors or infinite computations. We describe the motivation for and the semantics of parallel pattern-matching. We also describe the first available implementation of Haskell with parallel pattern-matching. The implementation works via a source-to-source translation into Concurrent Haskell, using the existing facilities of GHC to provide the required concurrency. Various transformation techniques are outlined which can help to reduce the degree and cost of the concurrency required to satisfy the semantics.

Abstract. We argue that abstract datatypes — with public interfaces hiding private implementations — represent a form of codata rather than ordinary data, and hence that proof methods for corecursive programs are the appropriate techniques to use for reasoning with them. In particular, we show that the universal properties of unfold operators are perfectly suited for the task. We illustrate with the solution to a problem in the recent literature. 1

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

Polytypic programming and data abstraction are important concepts in designing functional programs, but they do not fit well together. Polytypic programming currently depends on making public a free data type representation, while data abstraction depends on hiding the representation. This paper proposes the bialgebra views mechanism as a means of reconciling this conflict. Bialgebra views enable the specification of type structure according to interfaces, not representations, thus combining the genericity of polytypic programming with the information hiding of data abstraction, and narrowing the gap between generic programming in the functional and object-oriented paradigms. Categories and Subject Descriptors D.1.1 [Language Classifications]:

The world outside of academia lacks large scale real examples of applications written in functional programming languages. This technical report considers the development of one such application, a Geometric Modelling System. The core of the report describes the application in some depth. The report concludes with an appraisal of the results and considers the appropriateness of the functional programming style. 1 Introduction The advantages claimed of the functional programming style over the conventional imperative style are now well rehearsed [Jon84] [Hug89] [Hud89]. Even so functional languages have only flourished in the laboratories of academia. This fact is currently being addressed by the FLARE project. "The effectiveness of functional programming has been amply demonstrated on a laboratory scale and it is now appropriate to scale up the experiments with a view to encouraging the wider community of applications developers to embrace this technology." --- FLARE project proposal ...

This paper presents a type declaration construct which provides either a type synonym, a datatype, an abstract type, an abstract type with views, a subtype of an existing type, or a module (collection of declarations) . It supports the denition of views for an abstract type, allowing pattern-matching on values of abstract types. The presentation of the proposed construct is based on several illustrative examples. The combination of separate constructs into a single one has lead to an exploration of subtyping, with the distinction between concrete subtyping and abstract subtyping . Concrete subtyping can be based on an explicit rule for each type constructor, as usual, or on overloading of type constructors. Abstract subtyping is based either on: i) restriction of the set of values of the parent type through the use of constructor functions, or extension of the functionality of the parent type by modifying or providing new transformer or reader functions, or ii) on concrete subtyping ...