[TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages

[Greg Morrisett]

>I disagree that ADTs are equivalent to either modules or objects.  Read Cook's essay for a discussion of the latter; for the former, consider that it's often useful to define more than one ADT in a single module.

That's why I said "degenerate case". Modules, as strong sums, are more general. Objects are excessively narcissistic because they are fundamentally restricted to weak sums. 

> True, but type classes (which is what I assume you mean by first-class ADTs in Haskell) use type abstraction and therefore do not directly give you the properties you get from objects.
> 
> A critical property of objects, which is used architecturally in many OO systems, is support for heterogeneous data structures: e.g. putting several different implementations of an abstraction into a list.  You can do this is Haskell only through a "slightly clumsy" encoding that wraps a type class in another data structure, thereby existentially quantifying over the type class used.  See "Simulating objects" near the end of Simon Peyton Jones's talk:

I don't see this as clumsy at all. Rather, it's clumsy to abstract over operations that are uniform in most OO languages because they insist on conflating mechanisms that should be orthogonal. Haskell has a more proper separation of concerns.