Modular Type Classes - PowerPoint PPT Presentation

About This Presentation
Title:

Modular Type Classes

Description:

Elegant account of ad-hoc polymorphism ... Classes and Instances in ML. Great, but now how ... In Haskell, requires the introduction of 'equality constraints' ... – PowerPoint PPT presentation

Number of Views:41
Avg rating:3.0/5.0
Slides: 31
Provided by: tticUc
Learn more at: https://home.ttic.edu
Category:
Tags: classes | hoc | in | modular | type

less

Transcript and Presenter's Notes

Title: Modular Type Classes


1
Modular Type Classes
  • Derek Dreyer
  • Robert Harper
  • Manuel M.T. Chakravarty
  • POPL 2007
  • Nice, France

2
Specifications
  • Haskell

3
Specifications
  • Haskell

ML
4
Implementations
  • Haskell

5
Implementations
  • Haskell

ML
6
Generic Implementations
  • Haskell

7
Generic Implementations
  • Haskell

ML
8
Type Classes vs. Modules
  • Haskell type classes (Wadler and Blott, Jones, et
    al.)
  • Elegant account of ad-hoc polymorphism
  • May want different instances of integer equality
    to be canonical in different scopes
  • Not a substitute for a module system
  • ML modules (MacQueen, Harper, Leroy, et al.)
  • Explicit, fine-grained control over linking and
    abstraction
  • No support for implicit program construction

9
Our Proposal
  • Start with ML modules
  • Classes are just signatures of a special form
  • Instances are just structures and functors of a
    special form
  • Allow programmers to designate certain instance
    modules as canonical within a particular scope
  • No tradeoff necessary Get the best of both
    worlds!
  • Have access to full-featured module system by
    default
  • Can hook into the type inference engine and make
    use of Haskell-style overloading, if/when you
    want to

10
Classes and Instances in ML
  • Great, but now how do we create the eq function?

11
Creating an Overloaded Function
  • We employ an overload mechanism
  • This creates a polymorphic value eq,
    represented internally (in the semantics) as an
    implicit functor
  • Analogous to Haskells qualified types

12
Using eq
  • If we apply eq to some arguments of type int
    int
  • This initiates a demand for a canonical module of
    signature
  • But none exists ) Type error!

13
Making an Instance Canonical
  • Designate EqInt and EqProd as canonical in a
    certain scope

14
Making an Instance Canonical
  • Now if we apply eq in that scope
  • Then the above code typechecks and translates
    internally to
  • Similar to evidence translation in Haskell
  • Here we use modules as evidence

15
Class Hierarchies
  • Haskell subclass declaration

How to support class hierarchies using modules?
16
Class Hierarchies
  • Haskell subclass declaration
  • How to support class hierarchies using modules?
  • Use module hierarchies!

17
Composite Class Signatures
  • Instances of ORD are automatically computed
    frominstances of EQ and instances of LT

18
Associated Types
  • Proposed by Chakravarty et al. (2005) as an
    alternative tofunctional dependencies
  • Basic idea Add type components to classes
  • Falls out naturally from modular framework
  • Associated types are just type components of
    class signatures other than the one called t
  • In Haskell, requires the introduction of
    equality constraints
  • In ML, these are just where type constraints

19
What Else is in the Paper
  • Other design points
  • Coercions between implicit and explicit functors
  • Coherence in the presence of explicitly-scoped
    instances
  • Handling of overlapping instances
  • Type-theoretic formalization (details in the tech
    report)
  • Declarative elaboration semantics (a la
    Harper-Stone)
  • Type inference algorithm
  • Algorithm is sound, but not complete(due to
    problems inherited from both Haskell and ML)
  • Related work

20
Thank You!
21
Extra Slides
22
Associated Types(Chakravarty et al. 05)
  • A function sumColl that sums the elements of a
    collectionwould have polymorphic type

23
Haskell Approach
  • Beef up type classes
  • Multi-parameter classes (Jones, Peyton Jones, et
    al.)
  • Constructor classes (Jones 95)
  • Functional dependencies (Jones 00)
  • Associated types (Chakravarty et al. 05)
  • and more
  • Each extension brings classes closer to
    modules,but still no explicit control over
    linking
  • Only attempt at explicit control isnamed
    instances (Kahl and Scheffczyk 01)

24
Instance of Ord at Int
  • Haskell

25
Instance of Ord at Int
  • Haskell

ML
26
Instance of Ord at
  • Haskell

27
Instance of Ord at
  • Haskell

ML
28
Instance of Ord at
  • Haskell

ML
29
Computing a Composite Instance
  • Assuming LtInt and LtProd have been used, the
    canonical module of signature
  • is

30
Another Example
Write a Comment
User Comments (0)
About PowerShow.com