The views and conclusions contained in this document are those of the authors and should not be interpreted as

Cayenne is a Haskell-like language. The main difference between Haskell and Cayenne is that Cayenne has dependent types, i.e., the result type of a function may depend on the argument value, and types of record components (which can be types or values) may depend on other components. Cayenne also combines the syntactic categories for value expressions and type expressions; thus reducing the number of language concepts. Having dependent types and combined type and value expressions makes the language very powerful. It is powerful enough that a special module concept is unnecessary; ordinary records suffice. It is also powerful enough to encode predicate logic at the type level, allowing types to be used as specifications of programs. However, this power comes at a cost: type checking of Cayenne is undecidable. While this may appear to be a steep price to pay, it seems to work well in practice.

introduc e a notion of guarded rec ursive (g.r.) datatype c#w struc tors, generalizing the notion ofrec# rsive datatypes in func tional programming languages suc h as ML and Haskell. We address both theoret ic#t and prac# ic## issues resulted from this generalization. On one hand, we design a type system to formalize the notion of g.r. datatypec onstruc - tors and then prove the soundness of the type system. On the other hand, we present some signific ant applic ations (e.g., implementing objec ts, implementing stagedc omputation, etc# ) of g.r. datatype c# nstruc#S rs, arguing that g.r. datatypec onstruc torsc an have far-reac hingc onsequenc es in programming. The mainc ontribution of the paper lies in the rec#I0 ition and then the formalization of a programming notion that is of both theoretic# l interest and prac tic# l use.

This paper de nes a set of type inference rules for resolving overloading introduced by type classes. Programs including type classes are transformed into ones which may be typed by the Hindley-Milner inference rules. In contrast to other work on type classes, the rules presented here relate directly to user programs. An innovative aspect of this work is the use of second-order lambda calculus to record type information in the program. 1.

A number of useful optimisations are enabled if we can determine when a value is accessed at most once. We extend the Hindley-Milner type system with uses, yielding a typeinference based program analysis which determines when values are accessed at most once. Our analysis can handle higher-order functions and data structures, and admits principal types for terms. Unlike previous analyses, we prove our analysis sound with respect to call-by-need reduction. Call-by-name reduction does not provide an accurate model of how often a value is used during lazy evaluation, since it duplicates work which would actually be shared in a real implementation. Our type system can easily be modified to analyse usage in a call-by-value language. 1 Introduction This paper describes a method for determining when a value is used at most once. Our method is based on a simple modification of the Hindley-Milner type system. Each type is labelled to indicate whether the corresponding value is used at most onc...

We have constructed a practical tag-free garbage collector based on explicit type parameterization of polymorphic functions, for a dialect of ML. The collector relies on type information derived from an explicitly-typed 2nd-order representation of the program, generated by the compiler as a byproduct of ordinary Hindley-Milner type inference. Runtime type manipulations are performed lazily to minimize execution overhead. We present details of our implementation approach, and preliminary performance measurements suggesting that the overhead of passing type information explicitly can be made acceptably small. 1 Introduction Parametric polymorphic functions, as found in languages such as ML and Haskell, are traditionally compiled into code that executes uniformly regardless of the types of its arguments. This approach requires adopting a uniform data representation for all types. Typically, one pretends that every value fits in a single machine word; values that do not fit must be pointe...

The Gofer system is a functional programming environment for a small, Haskell-like language. Supporting a wide range of different machines, including home computers, the system is widely used, both for teaching and research. This report describes the main ideas and techniques used in the implementation of Gofer. This information will be particularly useful for work using Gofer as a platform to explore the use of new language features or primitives. It should also be of interest to those curious to see how the general techniques of functional programming language compilation are adapted to a simple, but practical, implementation.

We study a minimal extension of the Hindley#Milner system that supports overloading and polymorphic records. We show that the type system is sound with respect to a standard untyped compositional semantics. We also show that every typable term in this system has a principal type and give an algorithm to reconstruct that type. 1 Introduction Arithmetic, equality, showing a value as a string: three operations guaranteed to give a language designer nightmares. Usually they are dealt with by some form of overloading; but which form is best? Even if we limit our attention to languages based on the highly successful Hindley#Milner type system, we #nd many di#ering treatments of overloading. The same language may treat di#erent operators di#erently; di#erent languages may treat the same operator di#erently; and the same language may treat the same operator di#erently over time. For instance, in Miranda arithmetic is de#ned only on a single numeric type; equality is a polymorphic function ...

One of the most novel features in the functional programming language Haskell is the system of type classes used to support a combination of overloading and polymorphism. Current implementations of type class overloading are based on the use of dictionary 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.

Abstract It has often been suggested that functional languages provide an excellent basis for programming parallel computer systems. This is largely a result of the lack of side effects which makes it possible to evaluate the subexpressions of a given term without any risk of interference. On the other hand, the lack of side-effects has also been seen as a weakness of functional languages since it rules out many features of traditional imperative languages such as state, I/O and exceptions. These ideas can be simulated in a functional language but the resulting programs are sometimes unnatural and inefficient. On the bright side, recent work has shown how many of these features can be naturally incorporated into a functional language without compromising efficiency by expressing computations in terms of monads or continuations. Unfortunately, the "single-threading " implied by these techniques often destroys many opportunities for parallelism. In this paper, we describe a simple extension to the Haskell I/O monad that allows a form of explicit high-level concurrency. It is a simple matter to incorporate these features in a sequential implementation, and genuine parallelism can be obtained on a parallel machine. In addition, the inclusion of constructs for explicit concurrency enhances the use of Haskell as an executable specification language, since some programs are most naturally described as a composition of parallel processes. \Lambda This research was supported by ARPA via a subcontract to Intermetrics, Inc. 1