A path to enlightenment in Programming Language Theory

This project is maintained by Steven Shaw

Module Systems


Modular Type Classes

Modular Type Classes - the original paper.

These kinds of papers can be tough going but I recall that presentation gives you a really good intuition about it. QuickView

Extract of the SML code from the presentation/paper

The authors note that to make these “type classes” convenient in SML, you’d need to add implicit parameters (ala Scala - this is after Odersky’s “poor man’s type classes” but I’m not sure if they were inspired by it here).

A related paper with Stefan Wehr: Stefan further developed theses ideas in his thesis with a Java extension.

Derek Dreyer — Uber researcher on module systems.

Scott Kilpatrick (working on “modules” for Haskell - a better package system AFAIK). This is Backpack for Haskell/GHC.

Scott’s revelation when he finds the “modular type classes” work

MixML - ML module system inspired by Scala/Odersky Really like the look of this compared to OO-style mixin composition in Scala.

My understanding is the ML-style modules (i.e. modules from SML and OCaml) use a limited form of dependent typing. i.e. they are like records/structs with type members (in addition to fun/val members). They are not first-class like they are in Scala but special functions which operate on modules called functors (not to be confused with fmap-Functors or Applicative Functors). These module functors are parameterised modules.

Bruno Oliveira

Type Classes as Objects and Implicits (email to self 03-May-2012)

(Email to Mark Perry 31-Oct-2013)

Bruno Oliveira went on to write a paper about “implicits” with some other folks.

The idea is to study the “implicits” as a separate language feature that should be considered by language designers, or in their words “This calculus isolates and formalizes the key ideas of Scala implicits and provides a simple model for language designers interested in developing similar mechanisms for their own languages.”.


(Email to Mark Perty 31-Oct-2013)

Odersky introduced implicit parameters to Scala in version 2.0. BTW, this was when I started taking Scala more seriously (but not just because of the implicit parameters!).

He explained how that gets you to “type classes” at this talk:

and again (more formally) in 2010:

George Kuan

Modular type classes show-stopper?

(email to self, 08-Jul-2012) “In contrast, since the type of x is universally quantified, the canonical instance of Num a must be determined dynamically (i.e. passed in as an argument).”

Modular type classes and deriving

Practical Generic Programming with OCaml, Jeremy Yallop, LFCS, University of Edinburgh, ML Workshop 2007.

Orphan instances

(email to self, 11-May-2012)

It seems that Haskell’s Type Classes do find instances by linking only. i.e. instances are automatically exported/imported from the defining module (+ any recursively imported modules when importing).

“Partial Revelation feature of Modula-3 which causes similar problems like Haskell’s type class instances” Link to partial Revelation is broken. This might be a good substitute

IMO this is much better solved with “normal” scoping rules (including implicit definitions).

(Adapted from email to coq-study mailing list, 05-Mar-2013)