[TYPES] Issues regarding typeclasses and modular languages like ML

[rossberg@ps.uni-sb.de]

[I'm reposting this, because I had sent it from the wrong address, such
that it got auto-rejected.]

Following up on Derek's reply...

On Apr 9, 2009, at 05.11 h, Brian Hulley wrote:
> Another issue that is problematic concerns the question of identity of a
> type, for example:
>
> [...]
>
> I have not been able to find any papers that address the above issue,
> since they all seem to just use a pervasive type like (int) or tuples/
> lists thereof to illustrate their encoding of typeclasses. The issue
> concerns the meaning of "a posteriori" abstraction in ML, and the
> literature seems to be divided between merely hiding the relationship
> between an abstract type and its implementing type, or actually really
> generating a new distinct type (for the latter see [2]). Where does the
> notion of instance definition for "*the* type t" fit into this question?

The problem discussed in that paper is orthogonal to your concern - it
describes a way of distinguishing an abstract type and its representation
*at runtime*, as necessary in a language that has dynamic type analysis.
Whether or not you dynamically generate fresh type names is immaterial in
a language without such a feature (like conventional ML or Haskell). For
type classes, it only matters whether the types are distinguished
*statically*. As explained by Derek, that is the case (either way).

> The question *may* be addressed in "ML mit Typklassen" [3] but
> unfortunately although the examples are in English the text is in German
> and I think I would need more than just a pocket dictionary to try to
> follow the arguments therein. Does anyone know of an English
> translation, or, if the issue is addressed there, could anyone point me
> to the relevant section since with enough time I probably could
> translate a few paragraphs.

Since I co-supervised that thesis, I can lift that mystery, too. The
language presented in that thesis simply adds together ML-style modules
and Haskell-style type classes without any attempt to merge them. As such,
it is much less elegant than the MTC paper. With respect to abstract
types, it pretty much behaves the same: you can freely define instances
for an abstract type, because it is distinct from any other type.

Best,
- Andreas