this paper. Pleasingly, the arrow interface turned out to be applicable to other kinds of non-monadic library also, for example the fudgets library for graphical user interfaces [CH93], and a new library for programming active web pages. These applications will be described in sections 6 and 9. While arrows are a little less convenient to use than monads, they have significantly wider applicability. They can therefore be used to bring the benefits of monad-like programming to a much wider class of applications. 2 Background: Library Design Using Monads

this paper I will describe the results of using the functional language Haskell to build DSELs. Haskell has several features that make it particularly suitable for this, but other languages could also be used. On the other hand, there are features that don't exist in any language (to my knowledge) that would make things even easier; there is much more work to be done.

A domain specific language (DSL) allows one to develop software for a particular application domain quickly and effectively, yielding programs that are easy to understand, reason about, and maintain. On the other hand, there may be a significant overhead in creating the infrastructure needed to support a DSL. To solve this problem, a methodology is described for building domain specific embedded languages (DSELs), in which a DSL is designed within an existing, higher-order and typed, programming language such as Haskell or ML. In addition, techniques are described for building modular interpreters and tools for DSELs. The resulting methodology facilitates reuse of syntax, semantics, implementation code, software tools, as well as look-and-feel.

How canweintegrate interaction into a purely declarative language? This tutorial describes a solution to this problem based on a monad. The solution has been implemented in the functional language Haskell and the declarative language Escher. Comparisons are given to other approaches to interaction based on synchronous streams, continuations, linear logic, and side effects.

When type classes were first introduced in Haskell they were regarded as a fairly experimental language feature, and therefore warranted a fairly conservative design. Since that time, practical experience has convinced many programmers of the benefits and convenience of type classes. However, on occasion, these same programmers have discovered examples where seemingly natural applications for type class overloading are prevented by the restrictions imposed by the Haskell design. It is possible to extend the type class mechanism of Haskell in various ways to overcome these limitations, but such proposals must be designed with great care. For example, several different extensions have been implemented in Gofer. Some of these, particularly the support for multi-parameter classes, have proved to be very useful, but interactions between other aspects of the design have resulted in a type system that is both unsound and undecidable. Another illustration is the introduction of constructor cla...

Abstract. Refactoring is the process of improving the design of existing programs without changing their functionality. These notes cover refactoring in functional languages, using Haskell as the medium, and introducing the HaRe tool for refactoring in Haskell. 1

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.

. We show the benefits of applying modular monadic semantics to compiler construction. Modular monadic semantics allows us to define a language with a rich set of features from reusable building blocks, and use program transformation and equational reasoning to improve code. Compared to denotational semantics, reasoning in monadic style offers the added benefits of highly modularized proofs and more widely applicable results. To demonstrate, we present an axiomatization of environments, and use it to prove the correctness of a well-known compilation technique. The monadic approach also facilitates generating code in various target languages with different sets of built-in features. 1 Introduction We propose a modular semantics which allows language designers to add (or remove) programming language features without causing global changes to the existing specification, derive a compilation scheme from semantic descriptions, prove the correctness of program transformation and compilation...

There has already been considerable research on constructing modular, monad-based specications of computational effects (state, exceptions, nondeterminism, etc.) in programming languages. We present a simple framework in this tradition, based on a Church-style effect-typing system for an ML-like language. The semantics of this language is formally dened by a series of monadic translations, each one expanding away a layer of effects. Such a layered specication is easy to reason about, but its direct implementation (whether by parameterized interpretation or by actual translation) is often prohibitively inefficient. By exploiting deeper semantic properties of monads, however, it is also possible to derive a vastly more efficient implementation: we show that each layer of eects can be uniformly simulated by continuation-passing, and further that multiple such layers can themselves be simulated by a standard semantics for call/cc and mutable state. Thus, even multi-effect programs can be execu...

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 o#er parametric polymorphism, which allows the use of values that behave uniformly over a range of di#erent 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. 1