Type Classes with Functional Dependencies Mark P Jones, Oregon Graduate Institute The theory of relational databases meets

(&&) :: Bool  Bool  Bool Some values have just one type: length ::  a. List a  Int Some values have many types:

Some values have several types: (+) :: Int  Int  Int (+) :: Float  Int  Float (+) :: Float  Float  Float (+) :: Int  Float  Float Different implementations in each case … (+) :: …  …  …. Extensible: allows us to add new variants...

(+) :: arg 1  arg 2  res Each type for (+) has the same shape: arg 1 arg 2 res Int Float IntFloat ……… Capture the differences in a table: Add =

Type Classes in Haskell: class Add arg 1 arg 2 res where (+) :: arg 1  arg 2  res instance Add Int Int Int where (+) = primIntAdd instance Add Float Float Float where (+) = primFloatAdd … instance Add Int Float Float where x+y = (int2Float x) + y

( ) IntFloat The Hope:

( ) IntFloat a whereAdd Int Float a b Add a Float b The Reality:

Type inference is supposed to infer the most general (principal) type possible. instance Add Int Float Complex where (+) = … Nothing in the program tells us that we won’t later find an extension of (+): … so the types that we infer have to be general enough to allow for this.

 a.  b. (Add Int Float a, Add a Float b)  b The principal type of (1+2.3)+4.5 is: A complex type for such a simple example; An inaccurate type — we could be much more precise; An ambiguous type — we can’t give a well- defined semantics for this term.

WANTED! We need a way to:  Persuade type inference to produce better results …  … without compromising extensibility … Solution: let programmers specify type class relations more precisely.

Enter Database Theory: In the theory of (relational) databases:  Data is stored in tables/relations;  Designers specify constraints to capture semantic properties of the data;  Constraints help to ensure consistency and to avoid redundancy.

PILOTFLIGHTDATEDEPARTS Cushing839 Aug10:15am Cushing11610 Aug1:25pm Clark2818 Aug5:50pm Clark30112 Aug6:35pm Clark8311 Aug10:15am Chin8313 Aug10:15am Chin11612 Aug1:25pm From “The Theory of Relational Databases”, David Maier, 1983.

PILOTFLIGHTDATEDEPARTS Cushing839 Aug10:15am Cushing11610 Aug1:25pm Clark2818 Aug5:50pm Clark30112 Aug6:35pm Clark8311 Aug10:15am Chin8313 Aug10:15am Chin11612 Aug1:25pm DEPARTS is determined by FLIGHT

PILOTFLIGHTDATEDEPARTS Cushing839 Aug10:15am Cushing11610 Aug1:25pm Clark2818 Aug5:50pm Clark30112 Aug6:35pm Clark8311 Aug10:15am Chin8313 Aug10:15am Chin11612 Aug1:25pm PILOT is determined by FLIGHT, DATE

The database table corresponds to a relation on attributes {PILOT, FLIGHT, DATE, DEPARTS} that satisfies certain functional dependencies: {FLIGHT}  {DEPARTS} {FLIGHT, DATE}  {PILOT} The theory and practice of functional dependencies are well-developed.

X  Y If X and Y are sets of attributes, then: specifies that, for each tuple: the values of attributes in Y are uniquely determined by the values of the attributes in X. In symbols: for two tuples t, t’: If t |X =t’ |X, then t |Y = t’ |Y.

Type Classes with Functional Dependencies: class Add a b c where (+) :: a  b  c Type classes correspond to relations on types …

Type Classes with Functional Dependencies: class Add a b c | {a,b}  {c} where (+) :: a  b  c Type classes correspond to relations on types … use functional dependencies to specify them more precisely:

C is an arbitrary relation on types. class C a b where … D is a partial function on types. class D a b | {a}  {b} where … E is a partial 1-1 mapping on types. class E a b | {a}  {b}, {b}  {a} where …

The compiler must check that a program’s declaration are consistent with the dependencies: instance Add Int Int Int where (+) = primIntAdd instance Add Float Float Float where (+) = primFloatAdd … instance Add Int Float Float where x+y = (int2Float x) + y These are fine!

The compiler must check that a program’s declaration are consistent with the dependencies: instance Add Int Float Float where x+y = (int2Float x) + y instance Add Int Float Complex where (+) = … These are not!

( ) IntFloat a whereAdd Int Float a But:Add Int Float Float and so:a = Float The Payback:

( ) IntFloat whereAdd Float Float b And so:b = Float The Payback: Float b

( ) IntFloat The Payback:

Type Inference: We infer a type t and a set of constraints P for each term. We can apply “improving substitutions” at any point during type inference … and still get principal types.

Improvement: A substitution S improves a set of constraints P if it can be applied to P without changing the set of satisfiable instances. For example: [Float/b] improves {Add Float Float b} [a/b] improves {Add a b a, Add a b b}

More generally: Suppose the constraints in P entail C t and C t’, where t, t’ are tuples of types, and C has a dependency X  Y. If t |X =t’ |X, then: mgu(t |Y,t’ |Y ) improves P. mgu(t 1,t 2 ) computes most general unifiers.

class Collects e c where empty :: c insert :: e  c  c enum :: c  List e Other Examples:

class Collects e c | {c}  {e} where empty :: c insert :: e  c  c enum :: c  List e Other Examples:

class Collects e c | {c}  {e} where empty :: c insert :: e  c  c enum :: c  List e Other Examples: class FiniteMap i e fm where emptyFM:: fm lookup:: i  fm  Maybe e extend:: i  e  fm  fm

class Collects e c | {c}  {e} where empty :: c insert :: e  c  c enum :: c  List e Other Examples: class FiniteMap i e fm | {fm}  {i,e} where emptyFM:: fm lookup:: i  fm  Maybe e extend:: i  e  fm  fm

class Monad m  StateMonad s m where get:: m s set:: s  m () Other Examples:

class Monad m  StateMonad s m | {m}  {s} where get:: m s set:: s  m () Other Examples: etc …

Related Work: Type Classes (Wadler and Blott, 1989); Parametric Type Classes (Chen, Hudak, Odersky, 1992); Constructor Classes (Jones, 1993); Improvement for Qualified Types (Jones, 1995).

Conclusions: A small extension to the syntax of Haskell; A significant enhancement of multiple parameter type classes in several applications; Implementation distributed in recent versions of Hugs; Opportunities still for further improvement.

Functional dependencies can be used to explore the relationship between type classes and implicit parameters (Lewis et al, POPL’00). The interaction of functional dependencies with other aspects (e.g., overlapping instances) of extended Haskell type systems are not yet understood. Future Work:

What other opportunities might there be for exploiting the theory of databases in the design of practical type systems? Future Work: