Command-oriented functional programs are currently structured in an ad hoc way that makes the development of multiple user-interfaces difficult and error prone, and makes it difficult to abstractly understand a program's command-oriented behavior. To rectify this, we propose a software architecture for such programs that we call functional model-view-controller (MVC), by a rough analogy with object-oriented MVC. In functional MVC, a program is structured as a model (domain-specific aspects), view (abstract user) and controller (command loops). In contrast to object-oriented MVC, a controller is active, consisting of a number of recursive functions. It calls its view to get user input and to display results to the user; it calls its model to do domain-specific work. To increase adaptability, a controller should be parameterized by its model and view, using a function or an ML-style functor. With this approach, one can write terminal and graphical views; one can also write views that do abstract scripting. One can understand and reason about a program's command-oriented aspects at a high-level of abstraction by focusing on the controller. Of particular note is the way we are able to allow computations of the model to be monitored and aborted by view. We illustrate our approach with a case study of a complete application, written in Standard ML, and using Concurrent ML and the eXene X window system toolkit.

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.

Datatype-generic programming involves parametrization by the shape of data, in the form of type constructors such as `list of'. Most approaches to datatype-generic programming are developed in the lazy functional programming language Haskell. We argue that the functional object-oriented language Scala is in many ways a better setting. Not only does Scala provide equivalents of all the necessary functional programming features (such parametric polymorphism, higher-order functions, higher-kinded type operations, and type- and constructor-classes), but it also provides the most useful features of object-oriented languages (such as subtyping, overriding, traditional single inheritance, and multiple inheritance in the form of traits). We show how this combination of features benefits datatype-generic programming, using three different approaches as illustrations.

Earlier studies have introduced a list of high-level evaluation criteria to assess how well a language supports generic programming. Since each language that meets all criteria is considered generic, those criteria are not fine-grained enough to differentiate between two languages for generic programming. We refine these criteria into a taxonomy that captures differences between type classes in Haskell and concepts in C++, and discuss which differences are incidental and which ones are due to other language features. The taxonomy allows for an improved understanding of language support for generic programming, and the comparison is useful for the ongoing discussions among language designers and users of both languages.

The aim of our work is to provide an infrastructure for formal proofs over Generic Haskell-style polytypic programs. For this goal to succeed, we must have a definition of polytypic programming which is both fully formal and as close as possible to the definition in Generic Haskell. This paper provides such a definition.

Previous implementations of generic rewriting libraries have a number of limitations: they require the user to either adapt the datatype on which rewriting is applied, or the rewriting rules are specified as functions, which makes it hard or impossible to document, test, and analyse rules. We describe a library that demonstrates how to overcome these limitations by defining rules as datatypes, and how to use a type-indexed datatype to automatically extend a datatype with a case for meta-variables. We then show how to implement rules without knowledge of how the datatype is extended with meta-variables. We use Haskell extended with associated types to implement both type-indexed datatypes and generic functions. We analyse the performance of our library and compare it with other approaches to generic rewriting.