Mark P. Jones

Monad transformers and modular interpreters

We show how a set of building blocks can be used to construct programming language interpreters, and present implementations of such building blocks capable of supporting many commonly known features, including simple expressions, three different function call mechanisms (call-by-name, call-by-value and lazy evaluation), references and assignment, nondeterminism, first-class continuations, and program tracing. The underlying mechanism of our system is monad transformers, a simple form of abstraction for introducing a wide range of computational behaviors, such as state, I/O, continuations, and exceptions. Our work is significant in the following respects. First, we have succeeded in designing a fully modular interpreter based on monad transformers that incudes features missing from Steeles, Espinosas, and Wadlers earlier efforts. Second, we have found new ways to lift monad operations through monad transformers, in particular difficult cases not achieved in Moggis original work. Third, we have demonstrated that interactions between features are reflected in liftings and that semantics can be changed by reordering monad transformers. Finally, we have implemented our interpreter in Gofer, whose constructor classes provide just the added power over Haskells type classes to allow precise and convenient expression of our ideas. This implementation includes a method for constructing extensible unions and a form of subtyping that is interesting in its own right.

A system of constructor classes: overloading and implicit higher-order polymorphism

This paper describes a flexible type system which combines overloading and higher-order polymorphism in an implicitly typed language using a system of constructor classes – a natural generalization of type classes in Haskell. We present a wide range of examples which demonstrate the usefulness of such a system. In particular, we show how constructor classes can be used to support the use of monads in a functional language. The underlying type system permits higher-order polymorphism but retains many of many of the attractive features that have made the use of Hindley/Milner type systems so popular. In particular, there is an effective algorithm which can be used to calculate principal types without the need for explicit type or kind annotations. A prototype implementation has been developed providing, amongst other things, the first concrete implementation of monad comprehensions known to us at the time of writing. 1 An overloaded map function Many functional programs use the map function to apply a function to each of the elements in a given list. The type and definition of this function as given in the Haskell standard prelude [6] are as follows: map :: (a → b) → [a] → [b] map f [ ] = [ ] map f (x : xs) = f x : map f xs It is well known that the map function satisfies the familiar laws: map id = id map f . map g = map (f . g) A category theorist will recognize these observations as indicating that there is a functor from types to types whose object part maps any given type a to the list type [a] and whose arrow part maps each function f :: a → b to the function map f :: [a] → [b]. A functional programmer will recognize that similar constructions are also used with a wide range of other data types, as illustrated by the following examples: data Tree a = Leaf a | Tree a :ˆ: Tree a mapTree :: (a → b) → (Tree a → Tree b) mapTree f (Leaf x ) = Leaf (f x ) mapTree f (l :ˆ: r) = mapTree f l :ˆ: mapTree f r data Opt a = Just a | Nothing mapOpt :: (a → b) → (Opt a → Opt b) mapOpt f (Just x ) = Just (f x ) mapOpt f Nothing = Nothing Each of these functions has a similar type to that of the original map and also satisfies the functor laws given above. With this in mind, it seems a shame that we have to use different names for each of these variants. A more attractive solution would allow the use of a single name map, relying on the types of the objects involved to determine which particular version of the map function is required in a given situation. For example, it is clear that map (1+) [1 , 2 , 3 ] should be a list, calculated using the original map function on lists, while map (1+) (Just 1 ) should evaluate to Just 2 using mapOpt . Unfortunately, in a language using standard Hindley/Milner type inference, there is no way to assign a type to the map function that would allow it to be used in this way. Furthermore, even if typing were not an issue, use of the map function would be rather limited unless some additional mechanism was provided to allow the definition to be extended to include new datatypes perhaps distributed across a number of distinct program modules. 1.1 An attempt to define map using type classes The ability to use a single function symbol with an interpretation that depends on the type of its arguments is commonly known as overloading . While some authors dismiss overloading as a purely syntactic convenience, this is certainly not the case in Haskell which has a flexible type system that supports both (parametric) polymorphism and overloading based on a system of type classes [13]. One of the most attractive features of this system is that, although each primitive overloaded operator will require a separate definition for each different argument type, there is no need for these to be in the same module. Type classes in Haskell can be thought of as sets of types. The standard example is the class Eq which includes precisely those types whose elements can be compared using the (==) function. A simple definition might be: class Eq a where (==) :: a → a → Bool The equality operator can then be treated as having any of the types in the set { a → a → Bool | a ∈ Eq }. The elements of a type class are defined by a collection of instance declarations which may be distributed across a number of distinct program modules. For the type class Eq , these would typically include definitions of equality for integers, characters, lists, pairs and user-defined datatypes. Only a single definition is required for functions defined either directly or indirectly in terms of overloaded primitives. For example, assuming a collection of instances as above, the member function defined by: member :: Eq a ⇒ a → [a] → Bool member x [ ] = False member x (y : ys) = x == y | | member x ys can be used to test for membership in a list of integers, characters, lists, pairs, etc. See [5, 13] for further details about the use of type classes. Unfortunately, the system of type classes is not sufficiently powerful to give a satisfactory treatment for the map function; to do so would require a class Map and a type expression m(t) involving the type variable t such that S = {m(t) | t ∈ Map } includes (at least) the types: (a → b) → ([a] → [b]) (a → b) → (Tree a → Tree b) (a → b) → (Opt a → Opt b) (for arbitrary types a and b). The only possibility is to take m(t) = t and choose Map as the set of types S for which the map function is required: class Map t where map :: t instance Map ((a → b) → ([a] → [b])) where . . . instance Map ((a → b) → (Tree a → Tree b)) where . . . instance Map ((a → b) → (Opt a → Opt b)) where . . . This syntax is not permitted in the current syntax of Haskell but even if it were, it does not give a sufficiently accurate characterization of the type of map. For example, the principal type of map j . map i would be (Map (a → c → e), Map (b → e → d)) ⇒ c → d where a and b are the types of i and j respectively. This is complicated and does not enforce the condition that i and j have function types. Furthermore, the type is ambiguous (the type variable e does not appear to the right of the ⇒ symbol or in the assumptions). Under these conditions, we cannot guarantee a well-defined semantics for this expression (see [8], for example). Other attempts to define the map function, for example using multiple parameter type classes, have also failed for essentially the same reasons. 1.2 A solution using constructor classes A much better approach is to notice that each of the types for which the map function is required is of the form: (a → b) → (f a → f b). The variables a and b here represent arbitrary types while f ranges over the set of type constructors for which a suitable map function has been defined. In particular, we would expect to include the list constructor (which we will write as List), Tree and Opt as elements of this set which, motivated by our earlier comments, we will call Functor . With only a small extension to the Haskell syntax for type classes this can be described by: class Functor f where map :: (a → b) → (f a → f b) instance Functor List where map f [ ] = [ ] map f (x : xs) = f x : map f xs instance Functor Tree where map f (Leaf x ) = Leaf (f x ) map f (l :ˆ: r) = map f l :ˆ: map f r instance Functor Opt where map f (Just x ) = Just (f x ) map f Nothing = Nothing Functor is our first example of a constructor class. The following extract (taken from a session with the Gofer system which includes support for constructor classes) illustrates how the definitions for Functor work in practice: ? map (1+) [1,2,3] [2, 3, 4] ? map (1+) (Leaf 1 :^: Leaf 2) Leaf 2 :^: Leaf 3 ? map (1+) (Just 1) Just 2 Furthermore, by specifying the type of map function more precisely, we avoid the ambiguity problems mentioned above. For example, the principal type of map j . map i is simply Functor f ⇒ f a → f c provided that i has type (a → b) and that j has type (b → c).

Functional Programming with Overloading and Higher-Order Polymorphism

The Hindley/Milner type system has been widely adopted as a basis for statically typed functional languages. One of the main reasons for this is that it provides an elegant compromise between flexibility, allowing a single value to be used in different ways, and practicality, freeing the programmer from the need to supply explicit type information. Focusing on practical applications rather than implementation or theoretical details, these notes examine a range of extensions that provide more flexible type systems while retaining many of the properties that have made the original Hindley/Milner system so popular. The topics discussed, some old, but most quite recent, include higher-order polymorphism and type and constructor class overloading. Particular emphasis is placed on the use of these features to promote modularity and reusability.

A Theory of Qualified Types

Abstract This paper describes a general theory of overloading based on a system of qualified types. The central idea is the use of predicates in the type of a term, restricting the scope of universal quantification. A corresponding semantic notion of evidence is introduced and provides a uniform framework for implementing applications of this system, including Haskell style type classes, extensible records and subtyping. Working with qualified types in a simple, implicitly typed, functional language, we extend the Damas-Milner approach to type inference. As a result, we show that the set of all possible typings for a given term can be characterized by a principal type scheme, calculated by a type inference algorithm.

A principled approach to operating system construction in Haskell

We describe a monadic interface to low-level hardware features that is a suitable basis for building operating systems in Haskell. The interface includes primitives for controlling memory management hardware, user-mode process execution, and low-level device I/O. The interface enforces memory safety in nearly all circumstances. Its behavior is specified in part by formal assertions written in a programming logic called P-Logic. The interface has been implemented on bare IA32 hardware using the Glasgow Haskell Compiler (GHC) runtime system. We show how a variety of simple O/S kernels can be constructed on top of the interface, including a simple separation kernel and a demonstration system in which the kernel, window system, and all device drivers are written in Haskell.

The versatile link, a common project for super-LHC

A common project to develop a bi-directional, radiation tolerant, high speed (4.8 Gb/s) optical link for future high energy physics experiments is described. Due to be completed in 2012, it targets the upgrade programs of detectors installed at CERNs Large Hadron Collider (LHC). The development of radiation and magnetic field tolerant opto-electronic devices, fibre and connectors is described. Both Single-Mode and Multi-Mode versions of the system operating respectively at 850 nm and 1310 nm wavelength are proposed. First results at component and system level are presented, based mostly on commercially available devices.

Simplifying and improving qualified types

Qualified types provide a general framework for constrained type systems, with applications including type class overloading, subtyping and record calculi. This paper presents an extended version of the type inference algorithm used in previous work, that can take account of the satisfiability of constraints to obtain more accurate principal types. The new algorithm is obtained by adding two new rules, one for simplification and one for improvement of constraint sets. In particular, it permits a better treatment for the previously troublesome multiple parameter extensions of Haskell type classes. For example, a form of parametric type classes, proposed by Chen, Hudak and Odersky, can be viewed as a special case of this work.

First-class polymorphism with type inference

Languages like ML and Haskell encourage the view of values as first-class entities that can be passed as arguments or results of functions, or stored as components of data structures. The same languages offer parametric polymorphism, which allows the use of values that behave uniformly over a range of different types. But the combination of these features is not supported-- polymorphic values are not first-class. This restriction is sometimes attributed to the dependence of such languages on type inference, in contrast to more expressive, explicitly typed languages, like System F, that do support first-class polymorphism.This paper uses relationships between types and logic to develop a type system, FCP, that supports first-class polymorphism, type inference, and also first-class abstract datatypes. The immediate result is a more expressive language, but there are also long term implications for language design.

Dictionary-free overloading by partial evaluation

One of the most novel features in the functional programming language Haskell is the system oftype classes used to support a combination of overloading and polymorphism. Current implementations of type class overloading are based on the use ofdictionary values, passed as extra parameters to overloaded functions. Unfortunately, this can have a significant effect on run-time performance, for example, by reducing the effectiveness of important program analyses and optimizations.This paper describes how a simple partial evaluator can be used to avoid the need for dictionary values at run-time by generating specialized versions of overloaded functions. This eliminates the run-time costs of overloading. Furthermore, and somewhat surprisingly given the presence of multiple versions of some functions, for all of the examples that we have tried so far, specialization actually leads to a reduction in the size of compiled programs.

Using parameterized signatures to express modular structure

Module systems are a powerful, practical tool for managing the complexity of large software systems. Previous attempts to formulate a type-theoretic foundation for modular programming have been based on existential, dependent, or manifest types. These approaches can be distinguished by their use of different quantifiers to package the operations that a module exports together with appropriate implementation types. In each case, the underlying type theory is simple and elegant, but significant and sometimes complex extensions are needed to account for features that are important in practical systems, such as separate compilation and propagation of type information between modules.This paper presents a simple type-theoretic framework for modular programming using parameterized signatures. The use of quantifiers is treated as a necessary, but independent concern. Using familiar concepts of polymorphism, the resulting module system is easy to understand and admits true separate compilation. It is also very powerful, supporting high-order, polymorphic, and first-class modules without further extension.