Results 11  20
of
118
Type Classes: An Exploration of the Design Space
 In Haskell Workshop
, 1997
"... 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 occ ..."
Abstract

Cited by 91 (8 self)
 Add to MetaCart
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 multiparameter 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...
A transformationbased optimiser for Haskell
, 1998
"... Many compilers do some of their work by means of correctnesspreserving, and hopefully performanceimproving, program transformations. The Glasgow Haskell Compiler (GHC) takes this idea of "compilation by transformation" as its warcry, trying to express as much as possible of the compilat ..."
Abstract

Cited by 83 (12 self)
 Add to MetaCart
Many compilers do some of their work by means of correctnesspreserving, and hopefully performanceimproving, program transformations. The Glasgow Haskell Compiler (GHC) takes this idea of "compilation by transformation" as its warcry, trying to express as much as possible of the compilation process in the form of program transformations. This paper reports on our practical experience of the transformational approach to compilation, in the context of a substantial compiler.
A direct algorithm for type inference in the rank2 fragment of the secondorder λcalculus
, 1993
"... We study the problem of type inference for a family of polymorphic type disciplines containing the power of CoreML. This family comprises all levels of the stratification of the secondorder lambdacalculus by "rank" of types. We show that typability is an undecidable problem at every ran ..."
Abstract

Cited by 78 (14 self)
 Add to MetaCart
We study the problem of type inference for a family of polymorphic type disciplines containing the power of CoreML. This family comprises all levels of the stratification of the secondorder lambdacalculus by "rank" of types. We show that typability is an undecidable problem at every rank k >= 3 of this stratification. While it was already known that typability is decidable at rank 2, no direct and easytoimplement algorithm was available. To design such an algorithm, we develop a new notion of reduction and show howto use it to reduce the problem of typability at rank 2 to the problem of acyclic semiunification. A byproduct of our analysis is the publication of a simple solution procedure for acyclic semiunification.
Static Type Inference in a Dynamically Typed Language
 In Eighteenth Annual ACM Symposium on Principles of Programming Languages
, 1991
"... We present a type inference system for FL based on an operational, rather than a denotational, formulation of types. The essential elements of the system are a type language based on regular trees and a type inference logic that implements an abstract interpretation of the operational semantics of F ..."
Abstract

Cited by 64 (7 self)
 Add to MetaCart
We present a type inference system for FL based on an operational, rather than a denotational, formulation of types. The essential elements of the system are a type language based on regular trees and a type inference logic that implements an abstract interpretation of the operational semantics of FL. We use a nonstandard approach to type inference because our requirementsusing type information in the optimization of functional programsdiffer substantially from those of other type systems. 1 Introduction Compilers derive at least two benefits from static type inference: the ability to detect and report potential runtime errors at compiletime, and the use of type information in program optimization. Traditionally, type systems have emphasized the detection of type errors. Statically typed functional languages such as Haskell [HWA*88] and ML [HMT89] include type constraints as part of the language definition, making some type inference necessary to ensure that type constraints ...
Typability and Type Checking in System F Are Equivalent and Undecidable
 Annals of Pure and Applied Logic
, 1998
"... Girard and Reynolds independently invented System F (a.k.a. the secondorder polymorphically typed lambda calculus) to handle problems in logic and computer programming language design, respectively. Viewing F in the Curry style, which associates types with untyped lambda terms, raises the questions ..."
Abstract

Cited by 60 (4 self)
 Add to MetaCart
Girard and Reynolds independently invented System F (a.k.a. the secondorder polymorphically typed lambda calculus) to handle problems in logic and computer programming language design, respectively. Viewing F in the Curry style, which associates types with untyped lambda terms, raises the questions of typability and type checking . Typability asks for a term whether there exists some type it can be given. Type checking asks, for a particular term and type, whether the term can be given that type. The decidability of these problems has been settled for restrictions and extensions of F and related systems and complexity lowerbounds have been determined for typability in F, but this report is the rst to resolve whether these problems are decidable for System F. This report proves that type checking in F is undecidable, by a reduction from semiuni cation, and that typability in F is undecidable, by a reduction from type checking. Because there is an easy reduction from typability to typ...
Compiling Haskell by program transformation: a report from the trenches
 In Proc. European Symp. on Programming
, 1996
"... Many compilers do some of their work by means of correctnesspreserving, and hopefully performanceimproving, program transformations. The Glasgow Haskell Compiler (GHC) takes this idea of "compilation by transformation" as its warcry, trying to express as much as possible of the compilat ..."
Abstract

Cited by 55 (4 self)
 Add to MetaCart
Many compilers do some of their work by means of correctnesspreserving, and hopefully performanceimproving, program transformations. The Glasgow Haskell Compiler (GHC) takes this idea of "compilation by transformation" as its warcry, trying to express as much as possible of the compilation process in the form of program transformations. This paper reports on our practical experience of the transformational approach to compilation, in the context of a substantial compiler. The paper appears in the Proceedings of the European Symposium on Programming, Linkoping, April 1996. 1 Introduction Using correctnesspreserving transformations as a compiler optimisation is a wellestablished technique (Aho, Sethi & Ullman [1986]; Bacon, Graham & Sharp [1994]). In the functional programming area especially, the idea of compilation by transformation has received quite a bit of attention (Appel [1992]; Fradet & Metayer [1991]; Kelsey [1989]; Kelsey & Hudak [1989]; Kranz [1988]; Steele [1978]). A ...
CollectionOriented Languages
 PROCEEDINGS OF THE IEEE
, 1991
"... Several programming languages arising from widely diverse practical and theoretical considerations share a common highlevel feature: their basic data type is an aggregate of other more primitive data types and their primitive functions operate on these aggregates. Examples of such languages (and th ..."
Abstract

Cited by 52 (5 self)
 Add to MetaCart
Several programming languages arising from widely diverse practical and theoretical considerations share a common highlevel feature: their basic data type is an aggregate of other more primitive data types and their primitive functions operate on these aggregates. Examples of such languages (and the collections they support) are FORTRAN 90 (arrays), APL (arrays), Connection Machine LISP (xectors), PARALATION LISP (paralations), and SETL (sets). Acting on large collections of data with a single operation is the hallmark of dataparallel programming and massively parallel computers. These languages  which we call collectionoriented  are thus ideal for use with massively parallel machines, even though many of them were developed before parallelism and associated considerations became important. This paper examines collections and the operations that can be performed on them in a languageindependent manner. It also critically reviews and compares a variety of collectionoriented languages...
LetFloating: Moving Bindings to Give Faster Programs
 PROCEEDINGS OF THE 1996 ACM SIGPLAN INTERNATIONAL CONFERENCE ON FUNCTIONAL PROGRAMMING
, 1997
"... Virtually every compiler performs transformations on the program it is compiling in an attempt to improve efficiency. Despite their importance, however, there have been few systematic attempts to categorise such transformations and measure their impact. In this paper we describe a particular group o ..."
Abstract

Cited by 52 (12 self)
 Add to MetaCart
Virtually every compiler performs transformations on the program it is compiling in an attempt to improve efficiency. Despite their importance, however, there have been few systematic attempts to categorise such transformations and measure their impact. In this paper we describe a particular group of transformations  the "letfloating" transformations  and give detailed measurements of their effect in an optimising compiler for the nonstrict functional language Haskell. Letfloating has not received much explicit attention in the past, but our measurements show that it is an important group of transformations (at least for lazy languages), offering a reduction of more than 30% in heap allocation and 15% in execution time.
Parallel Programming using Functional Languages
, 1991
"... I am greatly indebted to Simon Peyton Jones, my supervisor, for his encouragement and technical assistance. His overwhelming enthusiasm was of great support to me. I particularly want to thank Simon and Geoff Burn for commenting on earlier drafts of this thesis. Through his excellent lecturing Cohn ..."
Abstract

Cited by 49 (3 self)
 Add to MetaCart
I am greatly indebted to Simon Peyton Jones, my supervisor, for his encouragement and technical assistance. His overwhelming enthusiasm was of great support to me. I particularly want to thank Simon and Geoff Burn for commenting on earlier drafts of this thesis. Through his excellent lecturing Cohn Runciman initiated my interest in functional programming. I am grateful to Phil Trinder for his simulator, on which mine is based, and Will Partain for his help with LaTex and graphs. I would like to thank the Science and Engineering Research Council of Great Britain for their financial support. Finally, I would like to thank Michelle, whose culinary skills supported me whilst I was writingup.The Imagination the only nation worth defending a nation without alienation a nation whose flag is invisible and whose borders are forever beyond the horizon a nation whose motto is why have one or the other when you can have one the other and both
ContextSensitive Rewriting Strategies
, 1997
"... Contextsensitive rewriting is a simple restriction of rewriting which is formalized by imposing fixed restrictions on replacements. Such a restriction is given on a purely syntactic basis: it is (explicitly or automatically) specified on the arguments of symbols of the signature and inductively ..."
Abstract

Cited by 43 (30 self)
 Add to MetaCart
Contextsensitive rewriting is a simple restriction of rewriting which is formalized by imposing fixed restrictions on replacements. Such a restriction is given on a purely syntactic basis: it is (explicitly or automatically) specified on the arguments of symbols of the signature and inductively extended to arbitrary positions of terms built from those symbols. Termination is not only preserved but usually improved and several methods have been developed to formally prove it. In this paper, we investigate the definition, properties, and use of contextsensitive rewriting strategies, i.e., particular, fixed sequences of contextsensitive rewriting steps. We study how to define them in order to obtain efficient computations and to ensure that contextsensitive computations terminate whenever possible. We give conditions enabling the use of these strategies for rootnormalization, normalization, and infinitary normalization. We show that this theory is suitable for formalizing ...