Modular Type Classes - the original paper.
Extract of the SML code from the presentation/paper https://github.com/steshaw/playground/blob/master/sml/typeClass.sml
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: http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf. Stefan further developed theses ideas in his thesis http://www.stefanwehr.de/ with a Java extension.
Derek Dreyer — Uber researcher on module systems.
Scott’s revelation when he finds the “modular type classes” work http://skilpat.tumblr.com/post/208298998/max-planck-and-modular-type-classes
MixML - ML module system inspired by Scala/Odersky http://www.mpi-sws.org/~rossberg/mixml/ 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.
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:
(email to self, 08-Jul-2012)
http://permalink.gmane.org/gmane.comp.science.types/4875 “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).”
Practical Generic Programming with OCaml, Jeremy Yallop, LFCS, University of Edinburgh, ML Workshop 2007.
(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 http://www.cs.tut.fi/lintula/manual/modula3/modula-3/html/partial-rev/index.html
IMO this is much better solved with “normal” scoping rules (including implicit definitions).
(Adapted from email to coq-study mailing list, 05-Mar-2013)