1 / 30

Modular Type Classes

This paper discusses the integration of modular type classes within Haskell, presenting a novel framework that combines the strengths of Haskell's type classes and ML's modular systems. It addresses issues of ad-hoc polymorphism, instance scoping, and the creation of overloaded functions. The proposed mechanism allows programmers to designate particular instances as canonical, enhancing type inference and providing modularity without sacrificing elegance. With discussions on class hierarchies, associated types, and overall design considerations, this work seeks to bridge the gap between type classes and modules effectively.

leia
Télécharger la présentation

Modular Type Classes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 canonicalwithin 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 Haskell’s 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 to“functional 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 is“named 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

More Related