[Haskell-cafe] Inheritance without OOHaskell

[John Goerzen]

Hello,

I'd like to put forth two situations in which I miss the ability to use
inheritance in Haskell, and then see if maybe somebody has some insight
that I'm missing out on.

Situation #1: In HDBC, there is a Connection type that is more or less
equivolent to a class on a OOP language.  In Haskell, we use a record
with named fields that represent functions.  Closures are used to permit
those functions to access internal state.  That works well enough.  But
there is no way at all to extend this.  Say a database such as
PostgreSQL has some extra features -- it would be nice for the
PostgreSQL objects to support additional functions, whereas Connection
objects from other databases might not support those functions.  Any
Haskell function could expect a Connection object (in which case it
could access only the standard functions) or a PostgreSQL object (in
which case it could access the standard plus the enhanced functions).

The internal state of a Connection object is DB-specific, so there can
be no general function to expose it.

Situation #2: In Python, every exception is an object, and every object
can be extended.  Therefore, I could write an exception handler for,
say, an IO error, and have it work for anything that's a subclass of the
generic IO error -- even if these subclasses weren't known at the time
the program was written.

Other handlers could be as specific or as general as desired.

In Haskell, it seems that all of this has to be anticipated in advance;
it's not very easy to extend things.

So my questions are:

1. I have sometimes used typeclasses instead of data records.  This
provides some of what I'm searching for, but has the unfortunate
side-effect that one can't very easily build a list of objects that may
not come from the same place but are nonetheless part of the class.  For
instance, had I used typeclasses for HDBC, I couldn't have a list of
Connection objects where some are from MySQL, some from PostgreSQL, etc.

2. As a library designer, what is the most friendly way around these 
problems that adheres to the principle of least surprise for Haskell
programmers?

3. How does one choose between a type class and a data record of
functions when both would meet the general needs?

4. Is there a way to solve these inheritance problems without resorting
to a library such as OOHaskell, which many Haskell programmers are not
familiar with?

Thanks,

-- John


-- 
John Goerzen <jgoerzen at complete.org>    GPG: 0x8A1D9A1F    www.complete.org
"Value your freedom, or you will lose it, teaches history.  `Don't bother us
with politics,' respond those who don't want to learn."