Results 1  10
of
35
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 89 (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 theory of overloading
 ACM Transactions on Programming Languages and Systems (TOPLAS
, 2002
"... Abstract We introduce a novel approach for debugging illtyped programs in the Hindley/Milner system. We map the typing problem for a program to a system of constraints each attached to program code that generates the constraints. We use reasoning about constraint satisfiability and implication to f ..."
Abstract

Cited by 53 (18 self)
 Add to MetaCart
Abstract We introduce a novel approach for debugging illtyped programs in the Hindley/Milner system. We map the typing problem for a program to a system of constraints each attached to program code that generates the constraints. We use reasoning about constraint satisfiability and implication to find minimal justifications of type errors, and to explain unexpected types that arise. Through an interactive process akin to declarative debugging, a user can track down exactly where a type error occurs. We are able to capture various extensions of the Hindley/Milner system such as type annotations and Haskellstyle type class overloading. The approach has been implemented as part of the Chameleon system.
The implementation of the Gofer functional programming system
, 1994
"... The Gofer system is a functional programming environment for a small, Haskelllike 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 implementat ..."
Abstract

Cited by 53 (4 self)
 Add to MetaCart
The Gofer system is a functional programming environment for a small, Haskelllike 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.
Firstclass Polymorphism with Type Inference
"... Languages like ML and Haskell encourage the view of values as firstclass 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 ..."
Abstract

Cited by 47 (0 self)
 Add to MetaCart
Languages like ML and Haskell encourage the view of values as firstclass 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 firstclass. 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 firstclass polymorphism. This paper uses relationships between types and logic to develop a type system, FCP, that supports firstclass polymorphism, type inference, and also firstclass abstract datatypes. The immediate result is a more expressive language, but there are also long term implications for language design. 1
Implementing Haskell overloading
 In Functional Programming Languages and Computer Architecture
, 1993
"... Haskell overloading poses new challenges for compiler writers. Until recently there have been no implementations of it which have had acceptable performance; users have been adviced to avoid it by using explicit type signatures. This is unfortunate since it does not promote the reusability of softwa ..."
Abstract

Cited by 44 (1 self)
 Add to MetaCart
Haskell overloading poses new challenges for compiler writers. Until recently there have been no implementations of it which have had acceptable performance; users have been adviced to avoid it by using explicit type signatures. This is unfortunate since it does not promote the reusability of software components that overloading really offers. In this paper we describe a number of ways to improve the speed of Haskell overloading. None of the techniques described here is particularly exciting or complicated, but taken together they may give an order of magnitude speedup for some programs using overloading. The techniques fall into two categories: speeding up overloading, and avoiding overloading altogether. For the second kind we borrow some techniques from partial evaluation. There does not seem to be a single implementation technique which is a panacea; but a number of different ones have to be put together to get decent performance. 1 Introduction Haskell, [Hud92], introduces a new ...
Principal Type Schemes for Functional Programs with Overloading and Subtyping
 Science of Computer Programming
, 1994
"... We show how the Hindley/Milner polymorphic type system can be extended to incorporate overloading and subtyping. Our approach is to attach constraints to quantified types in order to restrict the allowed instantiations of type variables. We present an algorithm for inferring principal types and ..."
Abstract

Cited by 44 (1 self)
 Add to MetaCart
We show how the Hindley/Milner polymorphic type system can be extended to incorporate overloading and subtyping. Our approach is to attach constraints to quantified types in order to restrict the allowed instantiations of type variables. We present an algorithm for inferring principal types and prove its soundness and completeness. We find that it is necessary in practice to simplify the inferred types, and we describe techniques for type simplification that involve shape unification, strongly connected components, transitive reduction, and the monotonicities of type formulas.
Ordersorted polymorphism in isabelle
 Logical Environments
, 1993
"... MLstyle polymorphism can be generalized from a singlesorted algebra of types to an ordersorted one by adding a partially ordered layer of “sorts ” on top of the types. Type inference proceeds as in the Hindley/Milner system, except that ordersorted unification of types is used. The resulting sys ..."
Abstract

Cited by 33 (2 self)
 Add to MetaCart
MLstyle polymorphism can be generalized from a singlesorted algebra of types to an ordersorted one by adding a partially ordered layer of “sorts ” on top of the types. Type inference proceeds as in the Hindley/Milner system, except that ordersorted unification of types is used. The resulting system has been implemented in Isabelle to permit type variables to range over userdefinable subsets of all types. Ordersorted polymorphism allows a simple specification of type restrictions in many logical systems. It accommodates userdefined parametric overloading and allows for a limited form of abstract axiomatic reasoning. It can also explain type inference with Standard ML’s equality types and Haskell’s type classes. 1
Type Checking Type Classes
 IN PROC. 20TH ACM SYMP. PRINCIPLES OF PROGRAMMING LANGUAGES
, 1993
"... We study the type inference problem for a system with type classes as in the functional programming language Haskell. Type classes are an extension of MLstyle polymorphism with overloading. We generalize Milner's work on polymorphism by introducing a separate context constraining the type variables ..."
Abstract

Cited by 31 (3 self)
 Add to MetaCart
We study the type inference problem for a system with type classes as in the functional programming language Haskell. Type classes are an extension of MLstyle polymorphism with overloading. We generalize Milner's work on polymorphism by introducing a separate context constraining the type variables in a typing judgement. This leads to simple type inference systems and algorithms which closely resemble those for ML. In particular we present a new unification algorithm which is an extension of syntactic unification with constraint solving. The existence of principal types follows from an analysis of this unification algorithm.
Faking It: Simulating Dependent Types in Haskell
, 2001
"... Dependent types reflect the fact that validity of data is often a relative notion by allowing prior data to affect the types of subsequent data. Not only does this make for a precise type system, but also a highly generic one: both the type and the program for each instance of a family of operations ..."
Abstract

Cited by 27 (6 self)
 Add to MetaCart
Dependent types reflect the fact that validity of data is often a relative notion by allowing prior data to affect the types of subsequent data. Not only does this make for a precise type system, but also a highly generic one: both the type and the program for each instance of a family of operations can be computed from the data which codes for that instance. Recent experimental extensions to the Haskell type class mechanism give us strong tools to relativize types to other types. We may simulate some aspects of dependent typing by making counterfeit typelevel copies of data, with type constructors simulating data constructors and type classes simulating datatypes. This paper gives examples of the technique and discusses its potential. 1
Type inference and semiunification
 In Proceedings of the ACM Conference on LISP and Functional Programming (LFP ) (Snowbird
, 1988
"... In the last ten years declarationfree programming languages with a polymorphic typing discipline (ML, B) have been developed to approximate the flexibility and conciseness of dynamically typed languages (LISP, SETL) while retaining the safety and execution efficiency of conventional statically type ..."
Abstract

Cited by 25 (6 self)
 Add to MetaCart
In the last ten years declarationfree programming languages with a polymorphic typing discipline (ML, B) have been developed to approximate the flexibility and conciseness of dynamically typed languages (LISP, SETL) while retaining the safety and execution efficiency of conventional statically typed languages (Algol68, Pascal). These polymorphic languages can be type checked at compile time, yet allow functions whose arguments range over a variety of types. We investigate several polymorphic type systems, the most powerful of which, termed MilnerMycroft Calculus, extends the socalled letpolymorphism found in, e.g., ML with a polymorphic typing rule for recursive definitions. We show that semiunification, the problem of solving inequalities over firstorder terms, characterizes type checking in the MilnerMycroft Calculus to polynomial time, even in the restricted case where nested definitions are disallowed. This permits us to extend some infeasibility results for related combinatorial problems to type inference and to correct several claims and statements in the literature. We prove the existence of unique most general solutions of term inequalities, called most general semiunifiers, and present an algorithm for computing them that terminates for all known inputs due to a novel “extended occurs check”. We conjecture this algorithm to be