[Haskell-cafe] Object oriented haskell.

[John Meacham]

I think every OO programmer coming to Haskell goes through this phase. They
start by attempting to use a haskell typeclass as they would a class in an
OO language, find it doesn't work and are a little miffed. Nevertheless they
persevere and are writing servicable if not idiomatic haskell and are
starting to get comfortable with Haskell's type system and experimenting in
it but they still feel the gentle tug of familier design patterns(tm) and
find themselves coding in a style trying to replicate them.

By this point they are familier enough with the haskell type system that
they start to realize they can simulate the behavior they are used to, hey,
an OO class is simply a type class combined with an existential type and a
default value all rolled into one! (which is more or less, completely true.)
So, they start making type classes that look like OO ones, restricting their
inherentence trees to be singular, using type class parameters in linear
covariant position because that is what they are used to and find things
good. they have replicated OO behavior, even got a working syntax down and
start programming in their own brand of OO-Haskell.

Then something happens. They go back to C++, or Java, or C#, and suddenly,
they feel horribly restricted. They start to wonder.. like. why do methods
only get to choose an implementation based on their first argument? Why the
heck is the class interface and an implementation related at all? why the
heck is code re-use tied to inherentence and why is multiple inheritence
tricky? why am I no longer happy?

They have had their flowers for algernon moment. While attempting to change
haskell to an OO language, Haskell has been changing them into a type system
hacker. while writing their restricted OO like class, they experimented
with other models of combining type classes with concrete data, perhaps by
accident and found them useful. They realized a data type they created was
an instance of a class and was able to declare that after the fact without
cahnging any existing code. They found that the ability for type inference
to work in any direction, and represent the relationship between types was
useful.

They are enlightened, and look back at their OO - Haskell framework as a
curiosity from their past. We all have one in our attic. An attempt at a
stock pattern shoehorned into something that a single higher order function
would solve. It's not a bad thing, It's part of learning Haskell. But there
is a reason most of these OO proposals tend to peter out. They just are not
really needed beyond a point.