[Haskell-cafe] OO idioms redux

[John Goerzen]

OK, recently I posed a question about rethinking some OO idioms, and
that spawned some useful discussion.

I now have a followup question.

One of the best features of OO programming is that of inheritance.  It
can be used to slightly alter the behavior of objects without requiring
modification to existing code or breaking compatibility with existing
APIs.

As an example, say I have a ConfigParser class.  This class can read in
configuration files, provides various get/set methods to access them,
and can write them back out.

Now say I would like to make this a little more powerful.  Maybe I want
to support the use of environment variables in my config file, so if
there's a reference to $FOO in the file, it will be replaced by the
contents of $FOO in the environment.

In OO, I would make a new EnvConfigParser class.  I'd override the
read() method.  My new read() would probably start by calling the
parent's read() method, to get parsing for free.  Then it could iterate
over the data, doing its environment variable substitution.


Now, in Haskell, we obviously have no objects like this.  We do have
something that provides some of the same benefits -- typeclasses.
However, from what I can determine, they don't support algorithm
inheritance like objects do in an OOP.  Specifically, it seems impossible to
have two instances of a single typeclass that work on the same type,
while having one share most of the code with the other.

I'm wondering if there is a Haskell design pattern that I'm missing that
would provid ethe kind of benefits that one gets from inheritance in the
OO world.

-- John


-- 
John Goerzen
Author, Foundations of Python Network Programming
http://www.amazon.com/exec/obidos/tg/detail/-/1590593715