Improved Inference for Checking Annotations (original) (raw)

Types Inference for Generic Haskell

The more expressive a type system, the more type infor- mation has to be provided in a program. Having to provide a type is sometimes a pain, but lacking expressivity is often even worse. There is a continuous struggle between expressivity and (type-)verbosity. How- ever, even very expressive type systems allow type inference for parts of a program. Generic Haskell is an extension of Haskell that supports defin- ing generic functions. Generic Haskell assumes that the type of a generic function is explicitly specified. This is often no problem, but sometimes it is rather painful to have to specify a type - in particular for generic functions with many dependencies - and sometimes the specified type can be generalized. In this paper, we identify three type inference prob- lems specific to generic functions, and present (partial) solutions to each of them.

Type inference with constrained types

Theory and Practice of Object Systems, 1999

In this paper we present a general framework HM(X) for Hindley/Milner style type systems with constraints. HM(X) stays in the tradition of the Hindley/Milner type system. Type systems in HM(X) are sound under a standard untyped compositional semantics that guarantees the slogan`well{typed programs can not go wrong'. Furthermore, we can give a generic type inference algorithm for HM(X). Under su cient conditions on X, type inference will always compute the principal type of a term. An instance of our framework which deals with polymorphic records is discussed. Also, we give a subtyping extension SHM(X) of our HM(X) system. In particular, the type inference algorithm for subtypes computes principal types. Simpli cation of the constraints inferred by the type inference algorithm is discussed for HM(X) and SHM(X).

Concoqtion: Mixing Indexed Types and Hindley-Milner Type Inference

2006

This paper addresses the question of how to extend OCaml's Hindley-Milner type system with types indexed by logical propositions and proofs of the Coq theorem prover, thereby providing an expressive and extensible mechanism for ensuring fine-grained program invariants. We propose adopting the approached used by Shao et al. for certified binaries. This approach maintains a phase distinction between the computational and logical languages, thereby limiting effects and non-termination to the computational language, and maintaining the decidability of the type system. The extension subsumes language features such as impredicative first-class (higher-rank) polymorphism and type operators, that are notoriously difficult to integrate with the Hindley-Milner style of type inference that is used in OCaml. We make the observation that these features can be more easily integrated with type inference if the inference algorithm is free to adapt the order in which it solves typing constraints to each program. To this end we define a novel "order-free" type inference algorithm. The key enabling technology is a graph representation of constraints and a constraint solver that performs Hindley-Milner inference with just three graph rewrite rules.

OutsideIn(X)Modular type inference with local assumptions

Journal of Functional Programming, 2011

Advanced type system features, such as GADTs, type classes, and type families, have proven to be invaluable language extensions for ensuring data invariants and program correctness. Unfortunately, they pose a tough problem for type inference when they are used as local type assumptions. Local type assumptions often result in the lack of principal types and cast the generalisation of local let-bindings prohibitively difficult to implement and specify. User-declared axioms only make this situation worse. In this article, we explain the problems and-perhaps controversially-argue for abandoning local let-binding generalisation. We give empirical results that local let generalisation is only sporadically used by Haskell programmers. Moving on, we present a novel constraint-based type inference approach for local type assumptions. Our system, called OutsideIn(X), is parameterised over the particular underlying constraint domain X, in the same way as HM(X). This stratification allows us to use a common metatheory and inference algorithm. OutsideIn(X) extends the constraints of X by introducing implication constraints on top. We describe the strategy for solving these implication constraints, which in turn relies on a constraint solver for X. We characterise the properties of the constraint solver for X so that the resulting algorithm only accepts programs with principal types, even when the type system specification accepts programs that do not enjoy principal types. Going beyond the general framework we give a particular constraint solver for X = type classes + GADTs + type families, a non-trivial challenge in its own right. This constraint solver has been implemented and distributed as part of GHC 7. Vytiniotis, Peyton Jones, Schrijvers, Sulzmann Contents 1 Introduction 2 The challenge we address 2.1 Modular type inference and principal types 2.2 The challenge of local constraints 2.3 The challenge of axiom schemes 2.4 Recovering principal types by enriching the type syntax 2.5 Summary 3 Constraint-based type systems 3.1 Syntax 3.2 Typing rules 3.3 Type soundness 3.4 Type inference, informally 3.5 Type inference, precisely 3.6 Soundness and principality of type inference 4 Constraint-based type systems with local assumptions 4.1 Data constructors with local constraints 4.2 let should not be generalised 4.3 Let (non)-generalization in practice 4.4 The lack of principal types 5 Type inference with OutsideIn(X) 5.1 Type inference, informally 5.2 Overview of the OutsideIn(X) solving algorithm 5.3 Top-level algorithmic rules 5.4 Generating constraints 5.5 Solving constraints 5.6 Variations on the design 5.7 Soundness and principality of type inference 6 Incompleteness and ambiguity 6.1 Incompleteness due to ambiguity 6.2 Incompleteness due to inconsistency 6.3 Incompleteness of the OutsideIn(X) strategy 6.4 Guess-free completeness 6.5 Our position on incompleteness and ambiguity 7 Instantiating X for GADTs, type classes, and type families 7.1 The entailment relation 7.2 Solving equality constraints is tricky 7.3 The simplifier 7.4 Rewriting constraints 7.5 The rule SIMPLES 7.6 Soundness and principality 7.7 Termination 8 Implementation 8.1 Evidence OutsideIn(X) 8.2 Brief sketch of the implementation 9 Related work 9.1 Constraint-based type inference 9.2 The special case of GADTs 9.3 The special case of multi-parameter type classes 9.4 Solving equalities involving type families 9.5 Let generalization for units of measure and type families 9.6 Ambiguity 9.7 Is the emphasis on principal types well-justified? 10 Future Work References

Lexically scoped type annotations

We observe that closed type annotations impose some serious restrictions on programs making use of typing features such as polymorphic recursion, type classes and guarded recursive data types. The type inferencer often cannot be supplied with the necessary amount of information to type check many reasonable programs. To address this, we introduce a novel form of lexically scoped annotation as an extension of Hindley/Milner. We further show that type inference based on algorithm Ï or its variants is not well-suited to deal with type annotations in general. Hence, we propose a novel inference scheme which improves over all previous formulations we are aware of. Our approach has been fully implemented as part of the Chameleon system (an experimental version of Haskell).

On Termination, Confluence and Consistent CHR-based Type Inference

Theory and Practice of Logic Programming, 2014

We consider the application of Constraint Handling Rules (CHR) for the specification of type inference systems, such as that used by Haskell. Confluence of CHR guarantees that the answer provided by type inference is correct and consistent. The standard method for establishing confluence relies on an assumption that the CHR program is terminating. However, many examples in practice give rise to non-terminating CHR programs, rendering this method inapplicable. Despite no guarantee of termination or confluence, the Glasgow Haskell Compiler (GHC) supports options that allow the user to proceed with type inference anyway, e.g. via the use of the UndecidableInstances flag. In this paper we formally identify and verify a set of relaxed criteria, namely range-restrictedness, local confluence, and ground termination, that ensure the consistency of CHR-based type inference that maps to potentially non-terminating CHR programs.

Type Debugging in the Hindley/Milner System with Overloading

We introduce a novel approach for debugging ill-typed 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 Haskell-style type class overloading. The approach has been implemented as part of the Chameleon system.

Principal Type Inference for GHC-Style Multi-parameter Type Classes

Lecture Notes in Computer Science, 2006

We observe that the combination of multi-parameter type classes with existential types and type annotations leads to a loss of principal types and undecidability of type inference. This may be a surprising fact for users of these popular features. We conduct a concise investigation of the problem and are able to give a type inference procedure which, if successful, computes principal types under the conditions imposed by the Glasgow Haskell Compiler (GHC). Our results provide new insights on how to perform type inference for advanced type extensions.

Type Inference for Multi-Parameter Type Classes

We observe that the combination of multi-parameter type classes with existential types and type annotations leads to a loss of principal types. As a consequence type inference in implementations such as GHC is incomplete. This may be a surprising fact for users of these standard features. We conduct a concise investigation of the problem and are able to precisely explain why we lose principality and completeness of inference. As remedy we propose several novel inference methods to retain completeness and principality.