Polymorphic type inference and abstract data types

Läufer, Konstantin; Odersky, Martin

doi:10.1145/186025.186031

Cited by 69 publications

(52 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Note that the semantics of GADTs are such that the x on the Bind constructor is an existential type [22]: it is instantiated to a specific type when a Bind is constructed, and then inaccessibly encapsulated by the constructor until the Bind is deconstructed through case analysis.…”

Section: Embedding Javascriptmentioning

confidence: 99%

The constrained-monad problem

et al. 2013

View full text Add to dashboard Cite

In Haskell, there are many data types that would form monads were it not for the presence of type-class constraints on the operations on that data type. This is a frustrating problem in practice, because there is a considerable amount of support and infrastructure for monads that these data types cannot use. Using several examples, we show that a monadic computation can be restructured into a normal form such that the standard monad class can be used. The technique is not specific to monads, and we show how it can also be applied to other structures, such as applicative functors. One significant use case for this technique is domain-specific languages, where it is often desirable to compile a deep embedding of a computation to some other language, which requires restricting the types that can appear in that computation. Categories and Subject Descriptors MotivationThe use of monads to structure computation was first suggested by Moggi [27,28] and Spivey [36], and was then enthusiastically taken up by Wadler [41,42]. Monads have since proved to be a popular and frequently occurring structure, and are now one of the most prevalent abstractions within the Haskell language.However, there are many data structures that are monad-like, but cannot be made instances of the Monad type class (Figure 1) because of type-class constraints on their operations. The classic example of this is the Set data type, which imposes an ordering constraint on its operations. This is unfortunate, because the Haskell language and libraries provide a significant amount of infrastructure to support arbitrary monads, including special syntax. We will refer to this situation where type-class constraints prevent a Monad instance from being declared as the "constrained-monad problem". This paper is about investigating solutions to this problem, with an emphasis on the particular solution of normalizing a deep embedding of a monadic computation. We aim to understand the utility of This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in ICFP '13, September 25-27, 2013, Boston, MA, USA, http://dx.doi.org/10.1145 class Monad (m :: * → * ) where the various solutions, publicize their usefulness, and explain how they relate to each other.We begin by giving three concrete examples of the constrainedmonad problem: three data types that would be monads were it not for the presence of class constraints on their operations.

show abstract

Section: Embedding Javascriptmentioning

confidence: 99%

The constrained-monad problem

et al. 2013

View full text Add to dashboard Cite

show abstract

“…This point, which avoids that right-hand sides restrict the types of variables more than left-hand sides, guarantees the type preservation property (i.e., that the expression resulting after a reduction step has the same type as the original one) when applying a program rule. Moreover, this point ensures a correct management of opaque variables (López-Fraguas et al, 2010)-either introduced by the presence of existentially quantified constructors or HO-patterns-which results in the support of a particular variant of existential types (Läufer and Odersky, 1994)-see Section 5.2 for more details. Finally, the last point guarantees that free variables in the set of assumptions are not modified by neither the most general typing substitutions of both sides nor the matching substitution.…”

Section: Well-typed Programsmentioning

confidence: 99%

“…Existential types (Mitchell and Plotkin, 1988;Perry, 1991;Läufer and Odersky, 1994) appear when type variables in the type of a constructor do not occur in the final type. For example the constructor key : ∀α.α → (α → nat) → key has an existential type, since α does not appear in the final type key, i.e., it has the equivalent type (∃α.α → (α → nat)) → key.…”

Section: Existential Types Opacity and Ho-patternsmentioning

confidence: 99%

“…more than the left-hand side does (α and α → nat resp.). However, the type system presented here gives a more permissive treatment to existential constructors than usual approaches (Mitchell and Plotkin, 1988;Perry, 1991;Läufer and Odersky, 1994). As a consequence, rules containing existential constructors with arguments of concrete types-as getKey (key z s) → z or getKey (key (s X ) F ) → s (F X)-are allowed provided right-hand sides does not restrict the types of the variables more than left-hand sides.…”

Section: Existential Types Opacity and Ho-patternsmentioning

confidence: 99%

See 1 more Smart Citation

Liberal Typing for Functional Logic Programs

López-Fraguas

Martin-Martin

Rodríguez-Hortalá

2010

Programming Languages and Systems

View full text Add to dashboard Cite

We propose a new type system for functional logic programming which is more liberal than the classical Damas-Milner usually adopted, but it is also restrictive enough to ensure type soundness. Starting from Damas-Milner typing of expressions we propose a new notion of well-typed program that adds support for type-indexed functions, a particular form of existential types, opaque higher-order patterns and generic functions-as shown by an extensive collection of examples that illustrate the possibilities of our proposal. In the negative side, the types of functions must be declared, and therefore types are checked but not inferred. Another consequence is that parametricity is lost, although the impact of this flaw is limited as "free theorems" were already compromised in functional logic programming because of non-determinism.

show abstract

“…If the system only had existential types in the style of Läufer and Odersky [1994], then environment fragments would be of the form ∃β.Γ. For instance, imagine we have K :: ∀ᾱβ.τ 1 × · · · × τ n → ε(ᾱ).…”

Section: Typing Judgmentsmentioning

confidence: 99%

A constraint-based approach to guarded algebraic data types

Simonet

Pottier

2007

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

We study HMG(X), an extension of the constraint-based type system HM(X) with deep pattern matching, polymorphic recursion, and guarded algebraic data types. Guarded algebraic data types subsume the concepts known in the literature as indexed types, guarded recursive datatype constructors, (first-class) phantom types, and equality qualified types, and are closely related to inductive types. Their characteristic property is to allow every branch of a case construct to be typechecked under different assumptions about the type variables in scope. We prove that HMG(X) is sound and that, provided recursive definitions carry a type annotation, type inference can be reduced to constraint solving. Constraint solving is decidable, at least for some instances of X, but prohibitively expensive. Effective type inference for guarded algebraic data types is left as an issue for future research. INTRODUCTIONMembers of the ML family of programming languages offer type inference in the style of Hindley [1969] andMilner [1978], making type annotations optional. Type inference can be decomposed into constraint generation and constraint solving phases, where constraints are, roughly speaking, systems of type equations. This remark has led to the definition of a family of constraint-based type systems, known as HM(X) [Odersky et al. 1999;Pottier and Rémy 2005], whose members exploit potentially more complex constraint languages, achieving greater expressiveness while still enjoying type inference in the style of Hindley and Milner.These programming languages also provide high-level facilities for defining and manipulating data structures, namely algebraic data types and pattern matching. In the setting of an explicitly typed calculus, Xi, Chen, and Chen [2003] have recently introduced guarded algebraic data types, an extension that offers significant new expressive power to programmers.The purpose of the present paper is to study how these two lines of research Permission to make digital/hard copy of all or part of this material without fee for personal or classroom use provided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/server notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or a fee. . 2005], it is necessary to study their interaction with Hindley-Milner-style type inference. Furthermore, because type inference is best understood in a constraint-based setting, and because constraint-based type systems are more general than Hindley and Milner's original type system, we believe it is worth studying an extension of HM(X) with guarded algebraic data types.We proceed as follows. First, we present an untyped call-by-value λ-calculus featuring data constructors and pattern matching ( §2). (We believe that our results could be transferred to a call-by-name calculus without difficulty.) The...

show abstract

Polymorphic type inference and abstract data types

Cited by 69 publications

References 6 publications

The constrained-monad problem

The constrained-monad problem

Liberal Typing for Functional Logic Programs

A constraint-based approach to guarded algebraic data types

Contact Info

Product

Resources

About