@article {IOPORT.01936238,
    author       = {Hall, Cordelia V. and Hammond, Kevin and Peyton Jones, Simon L. and Wadler, Philip L.},
    title        = {Type classes in Haskell.},
    year         = {1996},
    journal      = {ACM Transactions on Programming Languages and Systems},
    volume       = {18},
    number       = {2},
    issn         = {0164-0925},
    pages        = {109-138},
    publisher    = {Association for Computing Machinery, Inc. (ACM), New York, NY},
    doi          = {10.1145/227699.227700},
    abstract     = {Summary: \Beginpar{}{}{}This article defines a set of type inference rules for resolving overloading introduced by type classes, as used in the functional programming language Haskell. Programs including type classes are transformed into ones which may be typed by standard Hindley-Milner inference rules. In contrast to other work on type classes, the rules presented here relate directly to Haskell programs. An innovative aspect of this work is the use of second-order lambda calculus to record type information in the transformed program.\Endpar (Provider: ACM) Review: \Beginpar{}{}{}Type inferencing in a subset of Haskell that contains overloading (but not pattern matching) is described. The process involves adding extra parameters to overloaded functions, thus making the previously implicit typing explicit. Rules are provided for translating Haskell source into a target language (a typed lambda calculus with type abstraction and application).\Endpar \Beginpar{}{}{}A type class is a parameterized type with defined operations, possibly inheriting operations from another such class. When type classes are introduced in Haskell, environments are augmented to hold information about bindings. There are environments for six different kinds of objects. The translation of an expression requires extracting information from these environments to resolve the type of the expression, which is added to the translation.\Endpar \Beginpar{}{}{}I was left feeling vaguely uneasy. The outline discussing classes and instances is fine, and the translation approach as an implementation technique seems reasonable. However, computing has a long history of language features being defined by translation (for example, if-then-else defined via jumps), which can be a sign that the appropriate level of abstraction for the language feature has not yet been found. This concern was reinforced by the observation in the paper that Haskell proper has over 100 translation rules for types.\Endpar \Beginpar{}{}{}Leaving that aside, the paper should be of value to language designers and high-level implementors who want to learn techniques for managing types with inheritance. As the style is not particularly readable, it would probably not be of great interest to the casual computer scientist.\Endpar (Provider: ACM)},
    msc2010      = {F.3.3 (D.3.2 D.1.1)},
    identifier   = {01936238},
}