type classes with
DESCRIPTION
Type Classes with. Functional Dependencies. Mark P Jones, Oregon Graduate Institute. The theory of relational databases. meets. Some values have just one type:. (&&) :: Bool Bool Bool. Some values have many types:. length :: a. List a Int. - PowerPoint PPT PresentationTRANSCRIPT
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 resEach type for (+) has the same shape:
arg1 arg2 resInt Int IntInt Float Float
Float Int FloatFloat Float Float
… … …
Capture the differences in a table:
Add =
Type Classes in Haskell:class Add arg1 arg2 res where (+) :: arg1 arg2 resinstance Add Int Int Int where (+) = primIntAddinstance 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
t Float
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 DEPARTSCushing 83 9 Aug 10:15amCushing 116 10 Aug 1:25pmClark 281 8 Aug 5:50pmClark 301 12 Aug 6:35pmClark 83 11 Aug 10:15amChin 83 13 Aug 10:15amChin 116 12 Aug 1:25pm
From “The Theory of Relational Databases”, David Maier, 1983.
PILOT FLIGHT DATE DEPARTS
Cushing 83 9 Aug 10:15am
Cushing 116 10 Aug 1:25pmClark 281 8 Aug 5:50pmClark 301 12 Aug 6:35pmClark 83 11 Aug 10:15a
mChin 83 13 Aug 10:15a
mChin 116 12 Aug 1:25pmDEPARTS is determined by FLIGHT
PILOT FLIGHT DATE DEPARTS
Cushing 83 9 Aug 10:15am
Cushing 116 10 Aug 1:25pmClark 281 8 Aug 5:50pmClark 301 12 Aug 6:35pmClark 83 11 Aug 10:15a
mChin 83 13 Aug 10:15a
mChin 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 YIf X and Y are sets of attributes, then:
specifies that, for each tuple:the values of attributes in Yare uniquely determined by
thevalues 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 (+) = primIntAddinstance 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!
(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
t Float
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 whereempty :: cinsert :: e c cenum :: c List e
Other Examples:
class Collects e c | {c} {e} whereempty :: cinsert :: e c cenum :: c List e
Other Examples:
class Collects e c | {c} {e} whereempty :: cinsert :: e c cenum :: c List e
Other Examples:
class FiniteMap i e fm whereemptyFM :: fmlookup :: i fm Maybe eextend :: i e fm fm
class Collects e c | {c} {e} whereempty :: cinsert :: e c cenum :: c List e
Other Examples:
class FiniteMap i e fm | {fm}{i,e} where
emptyFM :: fmlookup :: i fm Maybe eextend :: i e fm fm
class Monad m StateMonad s m where
get :: m sset :: s m ()
Other Examples:
class Monad m StateMonad s m | {m} {s}
whereget :: m sset :: 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: