Composing and Decomposing Data Typesuniversity of copenhagendepartment of computer science Faculty of Science Composing and Decomposing Data Types A Closed Type Families Implementation

un i v er s i ty of copenhagen department of computer sc i ence

Faculty of Science

Composing and Decomposing Data TypesA Closed Type Families Implementationof Data Types a la Carte

Patrick BahrUniversity of Copenhagen,Department of Computer [email protected]

10th ACM SIGPLAN Workshop on Generic Programming, 31st August, 2014

Slide 1


Introduction

Experimenting with Closed Type Families

• What can we do with them?

• How do they compare to type classes?

• How do they interact with type classes?

Application: Data Types a la Carte

Specifically: the subtyping constraint :≺:

• Can we get rid of some of the restrictions?

• Can we improve error messages?

• What price do we have to pay?

Patrick Bahr — Composing and Decomposing Data Types — WGP ’14, 31st August, 2014

Slide 2


Introduction











Slide 2


Introduction











Slide 2


Data Types a la Carte [Swierstra 2008]

Idea: Decompose data types into two-level types:

Recursive data type

data Exp = Val Int| Add Exp Exp

=⇒

Fixpoint of functor

data Arith a = Val Int| Add a a

type Exp = Fix Arith

Functors can be combined by coproduct construction :+:

data Mul a = Mul a a

type Exp′ = Fix (Arith :+: Mul)


Slide 3




Recursive data type


=⇒

Fixpoint of functor







Slide 3




Recursive data type


=⇒

Fixpoint of functor







Slide 3




Recursive data type


=⇒

Fixpoint of functor



data Fix f = In (f (Fix f ))





Slide 3




Recursive data type


=⇒

Fixpoint of functor







Slide 3




Recursive data type


=⇒

Fixpoint of functor







Slide 3




Recursive data type


=⇒

Fixpoint of functor







Slide 3




Recursive data type


=⇒

Fixpoint of functor




data (f :+: g) a = Inl (f a)| Inr (g a)




Slide 3


Data Types a la Carte (cont.)

Subtyping constraint :≺:

class f :≺: g whereinj :: f a→ g aprj :: g a→ Maybe (f a)

e.g. Mul :≺: Arith :+: Mul

Example: smart constructors

add :: (Arith :≺: f )⇒ Fix f → Fix f → Fix fadd x y = In (inj (Add x y))

exp :: Fix (Arith :+: Mul)exp = val 1 ‘add ‘ (val 2 ‘mul ‘ val 3)


Slide 4










Slide 4










Slide 4










Slide 4


Limitations of :≺:

Definition of :≺:

instance f :≺: f where. . .

instance (f :≺: f1)⇒ f :≺: (f1 :+: f2) where. . .


• Asymmetric treatment of :+:

• Left-hand side is not inspected

• Ambiguity


Slide 5



Definition of :≺:


instance f :≺: (f :+: f2) where. . .




• Ambiguity


Slide 5



Definition of :≺:






• Ambiguity


Slide 5



Definition of :≺:




• Asymmetric treatment of :+: A :≺: A :+: (B :+: C )


• Ambiguity


Slide 5



Definition of :≺:




• Asymmetric treatment of :+: A :6≺: (A :+: B) :+: C


• Ambiguity


Slide 5



Definition of :≺:





• Left-hand side is not inspected A :+: B :≺: (A :+: B) :+: C

• Ambiguity


Slide 5



Definition of :≺:





• Left-hand side is not inspected A :+: B :6≺: A :+: (B :+: C )

• Ambiguity


Slide 5



Definition of :≺:





• Left-hand side is not inspected A :+: B :6≺: A :+: (B :+: C )

• Ambiguity A :≺: A :+: (A :+: B)


Slide 5


Contributions

We re-implemented :≺: such that:

• Subtyping behaves as intuitively expected*

• Ambiguous subtyping is avoided

• We can express isomorphism :':

*terms and conditions may applyPatrick Bahr — Composing and Decomposing Data Types — WGP ’14, 31st August, 2014

Slide 6


Improved subtyping constraint :≺:

Subtyping :≺: behaves as intuitively expected

f :≺: g ⇐⇒ ∃ unique injection from f to g

C :+: A :≺: A :+: B :+: C

Avoid ambiguous subtyping

Multiple occurrences of signatures are rejected:

A :≺: A :+: A :+: C

A :+: A :≺: A :+: B


Slide 7





C :+: A :≺: A :+: B :+: C



A :≺: A :+: A :+: C

A :+: A :≺: A :+: B


Slide 7





C :+: A :≺: A :+: B :+: C



A :≺: A :+: A :+: C

A :+: A :≺: A :+: B


Slide 7





C :+: A :≺: A :+: B :+: C



A :≺: A :+: A :+: C

A :+: A :≺: A :+: B


Slide 7





C :+: A :≺: A :+: B :+: C



A :≺: A :+: A :+: C

A :+: A :≺: A :+: B


Slide 7





C :+: A :≺: A :+: B :+: C



A :≺: A :+: A :+: C

A :+: A :≺: A :+: B

injection not unique!


Slide 7





C :+: A :≺: A :+: B :+: C



A :6≺: A :+: A :+: C

A :+: A :≺: A :+: B



Slide 7





C :+: A :≺: A :+: B :+: C



A :6≺: A :+: A :+: C

A :+: A :≺: A :+: B


“injection” not injective!


Slide 7





C :+: A :≺: A :+: B :+: C



A :6≺: A :+: A :+: C

A :+: A :6≺: A :+: B


“injection” not injective!


Slide 7


Type isomorphism constraint :':

We can express isomorphism :':

f :': g ⇐⇒ ∃ unique bijection from f to g

Easy to implement: f :': g = (f :≺: g , g :≺: f )

Use case: improved projection function

The type of the projection function is unsatisfying:

prj :: (f :≺: g)⇒ g a→ Maybe (f a)

With :': we can do better:

split :: (g :': f :+: r)⇒ g a→ Either (f a) (r a)


Slide 8












Slide 8












Slide 8












Slide 8










split :: (g :': f :+: r)⇒ g a→ (f a→ b)→ (r a→ b)→ b


Slide 8


Implementation of :≺:


Slide 9


Idea

Type-level function Embed :

• take two signatures f , g as arguments

• check whether f :≺: g

• check whether p also proves f :≺: g

Derive implementation of inj and prj :

• also use a type class

• But: use proof object as oracle in instance declarations

No singleton types. This all happens at compile time!


Slide 10


Idea



• check whether f :≺: g


Derive implementation of inj and prj : ???





Slide 10


Idea



• produce proof object p for f :≺: g







Slide 10


Idea










Slide 10


Idea










Slide 10


Idea



• produce proof object p for f :≺≺: g







Slide 10


Idea



• produce proof object p for f :≺≺: g







Slide 10


Proof Objects

Definition

data Prf = Refl | Left Prf | Right Prf | Sum Prf Prf

Refl : f :≺≺: f

p : f :≺≺: g1Left p : f :≺≺: g1 :+: g2

p : f :≺≺: g2Right p : f :≺≺: g1 :+: g2

p1 : f1 :≺≺: g p2 : f2 :≺≺: g

Sum p1 p2 : f1 :+: f2 :≺≺: g


Slide 11


Proof Objects

Definition


Refl : f :≺≺: f

p : f :≺≺: g1Left p : f :≺≺: g1 :+: g2

p : f :≺≺: g2Right p : f :≺≺: g1 :+: g2

p1 : f1 :≺≺: g p2 : f2 :≺≺: g

Sum p1 p2 : f1 :+: f2 :≺≺: g


Slide 11


Proof Objects

Definition


Refl : f :≺≺: f

p : f :≺≺: g1Left p : f :≺≺: g1 :+: g2

p : f :≺≺: g2Right p : f :≺≺: g1 :+: g2

p1 : f1 :≺≺: g p2 : f2 :≺≺: g

Sum p1 p2 : f1 :+: f2 :≺≺: g


Slide 11


Proof Objects

Definition


Refl : f :≺≺: f

p : f :≺≺: g1Left p : f :≺≺: g1 :+: g2

p : f :≺≺: g2Right p : f :≺≺: g1 :+: g2

p1 : f1 :≺≺: g p2 : f2 :≺≺: g

Sum p1 p2 : f1 :+: f2 :≺≺: g


Slide 11


Proof Objects

Definition


Refl : f :≺≺: f

p : f :≺≺: g1Left p : f :≺≺: g1 :+: g2

p : f :≺≺: g2Right p : f :≺≺: g1 :+: g2

p1 : f1 :≺≺: g p2 : f2 :≺≺: g

Sum p1 p2 : f1 :+: f2 :≺≺: g

kind


Slide 11


Proof Objects

Definition


Refl : f :≺≺: f

p : f :≺≺: g1Left p : f :≺≺: g1 :+: g2

p : f :≺≺: g2Right p : f :≺≺: g1 :+: g2

p1 : f1 :≺≺: g p2 : f2 :≺≺: g

Sum p1 p2 : f1 :+: f2 :≺≺: g

kind type


Slide 11


Proof Objects

Definition


Refl : f :≺≺: f

p : f :≺≺: g1Left p : f :≺≺: g1 :+: g2

p : f :≺≺: g2Right p : f :≺≺: g1 :+: g2

p1 : f1 :≺≺: g p2 : f2 :≺≺: g

Sum p1 p2 : f1 :+: f2 :≺≺: g

kind type

type constructor


Slide 11


Construct Proof Objects

data Emb = Found Prf | NotFound | Ambiguous

type family Embed (f :: ∗ → ∗) (g :: ∗ → ∗) :: Emb where

Embed f f = Found ReflEmbed (f1 :+: f2) g = Sum′ (Embed f1 g) (Embed f2 g)Embed f (g1 :+: g2) = Choose (Embed f g1) (Embed f g2)Embed f g = NotFound

type family Choose (e1 :: Emb) (e2 :: Emb) :: Emb whereChoose (Found p1) (Found p2) = AmbiguousChoose Ambiguous e2 = AmbiguousChoose e1 Ambiguous = AmbiguousChoose (Found p1) e2 = Found (Left p1)Choose e1 (Found p2) = Found (Right p2)Choose NotFound NotFound = NotFound


Slide 12








Slide 12








Slide 12








Slide 12


Post-Processing

This is almost what we want.

• We avoid ambiguity on the right-hand side:

A :6≺: A :+: A :+: C

• We still have ambiguity on the left-hand side:

A :+: A :≺: A :+: B

Solution: check for duplicates in Prf

type family Dupl (p :: Prf ) :: Bool where. . .


Slide 13


Post-Processing



A :6≺: A :+: A :+: C


A :+: A :≺: A :+: B




Slide 13


Post-Processing



A :6≺: A :+: A :+: C


A :+: A :≺: A :+: B




Slide 13


Post-Processing



A :6≺: A :+: A :+: C


A :+: A :≺: A :+: B




Slide 13


Post-Processing



A :6≺: A :+: A :+: C


A :+: A :≺: A :+: B



Sum (Left Refl) (Left Refl)


Slide 13


Are we there yet?

• Construct proof p for f :≺≺: g

X

• Check whether p proves f :≺: g

X

• Derive inj and prj


Slide 14


Are we there yet?

• Construct proof p for f :≺≺: g X

• Check whether p proves f :≺: g

X



Slide 14


Are we there yet?


• Check whether p proves f :≺: g X



Slide 14


Are we there yet?


• Check whether p proves f :≺: g X



Slide 14


Derive inj and prj


type f :≺: g = Sub (Embed f g) f g

instance f :≺: f where . . .

instance f :≺: (f :+: g2) where . . .

instance f :≺: g2⇒ f :≺: (g1 :+: g2) where . . .

instance ( f1 :≺: g , f2 :≺: g)⇒ (f1 :+: f2) :≺: g where . . .


Slide 15


Derive inj and prj








Slide 15


Derive inj and prj








Slide 15


Derive inj and prj

class Sub f g whereinj :: f a→ g aprj :: g a→ Maybe (f a)


instance Sub f f where . . .

instance Sub f g1⇒ Sub f (g1 :+: g2) where . . .


instance (Sub f1 g ,Sub f2 g)⇒ Sub (f1 :+: f2) g where . . .


Slide 15


Derive inj and prj

class Sub (e :: Emb) f g whereinj :: f a→ g aprj :: g a→ Maybe (f a)


instance Sub f f where . . .



instance (Sub f1 g ,Sub f2 g)⇒ Sub (f1 :+: f2) g where . . .


Slide 15


Derive inj and prj



instance Sub (Found Refl) f f where . . .

instance Sub (Found p) f g1⇒ Sub (Found (Left p)) f (g1 :+: g2) where . . .

instance Sub (Found p) f g2⇒ Sub (Found (Right p)) f (g1 :+: g2) where . . .

instance (Sub (Found p1) f1 g ,Sub (Found p2) f2 g)⇒ Sub (Found (Sum p1 p2)) (f1 :+: f2) g where . . .


Slide 15


Derive inj and prj



instance Sub (Found Refl) f f where . . .

instance Sub (Found p) f g1⇒ Sub (Found (Left p)) f (g1 :+: g2) where . . .

instance Sub (Found p) f g2⇒ Sub (Found (Right p)) f (g1 :+: g2) where . . .

instance (Sub (Found p1) f1 g ,Sub (Found p2) f2 g)⇒ Sub (Found (Sum p1 p2)) (f1 :+: f2) g where . . .


Slide 15


Conclusion

• This approach generalises to similar applications

• Improves type class-based implementation in manyaspects

• But:

• We need a way to customise error messages.

• Compile time performance unpredictable.

• Implemented in the compdata package

> cabal install compdata


Slide 16


Conclusion



• But:






Slide 16


Conclusion



• But:






Slide 16


Discussion


Slide 17


Error Messages

• A :≺: B :+: C ?

No instance for

(Sub NotFound A (B :+: C))

• A :+: A :≺: A :+: B ?

No instance for

(Sub Ambiguous (A :+: A) (A :+: B))

• A :≺: A :+: B ?

No instance for

(Sub (Post (Embed a (a :+: B))) a (a :+: B))


Slide 18


Error Messages

• A :≺: B :+: C ?

No instance for


• A :+: A :≺: A :+: B ?

No instance for


• A :≺: A :+: B ?

No instance for



Slide 18


Error Messages

• A :≺: B :+: C ?

No instance for


The original implementation would give:

No instance for (A :<: C)

• A :+: A :≺: A :+: B ?

No instance for


• A :≺: A :+: B ?

No instance for



Slide 18


Error Messages

• A :≺: B :+: C ?

No instance for


• A :+: A :≺: A :+: B ?

No instance for


• A :≺: A :+: B ?

No instance for



Slide 18


Error Messages

• A :≺: B :+: C ?

No instance for


• A :+: A :≺: A :+: B ?

No instance for


• A :≺: A :+: B ?

No instance for



Slide 18


Error Messages

• A :≺: B :+: C ?

No instance for


• A :+: A :≺: A :+: B ?

No instance for


• a :≺: a :+: B ?

No instance for



Slide 18


Error Messages

• A :≺: B :+: C ?

No instance for


• A :+: A :≺: A :+: B ?

No instance for


• a :≺: a :+: B ?

No instance for



Slide 18


Compile Time Performance

• If done “wrong”, this implementation can be very slow!

• Implementation presented here: O(n2)

• Slightly different implementation: O(2n)(but essentially the same)

• micro benchmark:• derive F :≺: G• 9 summands in F and G• Implementation presented here: 0.5s• Naive implementation: 45s

• Type families on kind ∗ are expensive!


Slide 19









Slide 19









Slide 19






• micro benchmark:• derive F :≺: G• 9 summands in F and G

• Implementation presented here: 0.5s• Naive implementation: 45s



Slide 19






• micro benchmark:• derive F :≺: G• 9 summands in F and G• Implementation presented here: 0.5s

• Naive implementation: 45s



Slide 19









Slide 19









Slide 19

Documents

Composing and Decomposing Data Typesuniversity of copenhagendepartment of computer science Faculty of Science Composing and Decomposing Data Types A Closed Type Families Implementation