Object-Oriented Style Overloading for Haskell

Mark Shields and Simon Peyton Jones. In the Workshop on Multi-Language Infrastructure and Interoperability (BABEL'01), Florence, Italy. 20 pages. Sep 2001.

A technical report version of this paper is also available. 31 pages.

Errata (in both versions}

Fig 2, page 14 (conference version) or page 12 (tech report version): the declaration
```
  class SubE e
```
should read
```
  class (SubI e, SubJ e) => SubE e
```
Similarly, in the same Figure, the declaration for class SubF should read
```
  class (SubE e) => SubF e
```

Abstract

Haskell has a sophisticated mechanism for overloading identifiers with multiple definitions at distinct types. Object-oriented programming has a similar notion of overriding and overloading for methods names. Unfortunately, it is not possible to encode object-oriented overloading directly using Haskell overloading. This deficiency becomes particularly tiresome when Haskell programs wish to call methods imported from an object-oriented library. We explore various encodings of object-oriented classes into Haskell, demonstrate precisely where Haskell's existing type class system is unsatisfactory, and propose two refinements. We proceed in three stages. Firstly, we discuss various ways of accommodating sub-typing; we conclude that a simple encoding using Haskell classes is better for our purpose than a more substantial language extension. Second, we introduce a new notion of closed class, and show how this enables improvement of constraints beyond what is possible in Haskell. Closed classes make it easy to encode the truely ad hoc overloading of object-oriented methods without the need for name mangling or gratuitous type annotations. Thirdly, we allow overlapping instances, and define what it means for one instance to be better than another. This mechanism will turn out to mimic the rather complex overloading resolution rules used by object-oriented languages to select the most-specific method at a call site. In the Appendix, we present type checking and inference rules, as well as details of constraint entailment and simplification. However, this workshop paper is somewhat exploratory: the design may shift once we gain experience with an implementation, and we have not devoted any time to showing any formal properties of our system.