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

Type Classes withFunctional

DependenciesMark P Jones, Oregon Graduate Institute

The theoryof

relationaldatabases

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 ...

(+) :: arg1 arg2 res

Each type for (+) has the same shape:

arg1 arg2 resInt Int Int

Int Float Float

Float Int Float

Float Float Float

… … …

Capture the differences in a table:

Add =

Type Classes in Haskell:class Add arg1 arg2 res where

(+) :: arg1 arg2 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

(1 + 2.3) + 4.5Int Floa

tFloa

tFloa

tFloat

The Hope:

(1 + 2.3) + 4.5Int Floa

tFloa

ta

where Add 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.

PILOT FLIGHT DATE DEPARTS

Cushing 83 9 Aug 10:15am

Cushing 116 10 Aug 1:25pm

Clark 281 8 Aug 5:50pm


Clark 83 11 Aug 10:15am

Chin 83 13 Aug 10:15am

Chin 116 12 Aug 1:25pm

From “The Theory of Relational Databases”, David Maier, 1983.








Chin 116 12 Aug 1:25pmDEPARTS is determined by FLIGHT








Chin 116 12 Aug 1:25pmPILOT 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

…


These are fine!

The compiler must check that a program’s declaration are consistent with the dependencies:


instance Add Int Float Complex where (+) = …

These are not!

(1 + 2.3) + 4.5Int Floa

ta

where Add Int Float aBut: Add Int Float Floatand so: a = Float

The Payback:

(1 + 2.3) + 4.5Int Floa

tFloa

t

where Add Float Float bAnd so: b = Float

The Payback:

Float

b

(1 + 2.3) + 4.5Int Floa

tFloa

tFloa

tFloat

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(t1,t2) 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:


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


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:

Documents

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