Understanding functional dependencies via constraint handling rules

Abstract

Functional dependencies are a popular and useful extension to Haskell style type classes. We give a reformulation of functional dependencies in terms of Constraint Handling Rules (CHRs). In previous work, CHRs have been employed for describing user-programmable type extensions in the context of Haskell style type classes. Here, we make use of CHRs to provide for the first time a concise result that under some sufficient conditions, functional dependencies allow for sound, complete and decidable type inference. The sufficient conditions imposed on functional dependencies can be very limiting. We show how to safely relax these conditions and suggest several sound extensions of functional dependencies. Our results allow for a better understanding of functional dependencies and open up the opportunity for new applications.

Injective type families for Haskell

“…Indeed, the improvement rules of Section 5 correspond precisely to the improvement rules for functional dependencies (Sulzmann et al 2007). …”

Haskell Type Constraints Unleashed

“…The reason is that the Paterson conditions for termination of type class instances [12,Def. 11] already require a strict size decrease of type terms from the instance head to individual constraints in the instance context.…”

Generic programming with C++ concepts and Haskell type classes—a comparison

“…Despite thorough analysis (Sulzmann et al 2007b), functional dependencies remain a controversial feature: Chakravarty et al (2005a) argues that associated types provide much of the functionality but cause less complexity in the type system.…”

“…Conversely, one then faces the problem of undecidability of the conceptchecking algorithm. In Haskell indeed, solving a set of constraints given a set of rules (given by modellings) can be potentially non-terminating: using a parametric modelling that has non-trivial assertions can make the set of constraints bigger, and if the rule can be applied again, the solver will never converge (Sulzmann et al 2007b). In C++, non-termination can also occur in a corresponding situation.…”