[Haskell-cafe] [Newbie] Quest for inheritance

Cédric Paternotte cpaternotte at gmail.com
Sun Jun 5 09:52:13 EDT 2005

Hi. This is my first message here so Hello to everyone.

I'm just starting to learn Haskell and I really think it's a cool language.

Coming from an OO world, I've been looking for ways to achieve
inheritance as you get it in Java and the likes.

I know OO and inheritance is not really the point of Haskell and that
other mechanisms are provided to somewhat achieve reuse. But it's a
way of programming I've been so used to that I feel lost without it.
You might think I'm heading in the wrong direction. My mistake I have
to agree. Let's take it as a learning exercise then.

So I've been searching the net for *easy* ways to get it and the least
I can say is that I'm confused. It soon became apparent that,
inheritance not being a core feature of the language, many people have
been hacking Haskell to come up with similar effects (btw I never
thought there could be so many ways to reach the same goal...Haskell
programmers are clever bastards). Of the many implementations that
I've found, few are really simple and most achieve it with various
levels of success and/or dodgy syntax.

Here are the various techniques I've come across so far :
(I'm far from understanding them all)

1. Through existential types

As shown in the Shapes example at
However, I couldn't spot the advantage over the standard version using
normal classes at

The getX function still needs to be defined in both RectangleInstance
and CircleInstance. This is not what I call inheritance. Inheritance
would make it possible to define getX only once in ShapeInstance. Or
maybe the point was only to demonstrate polymorphism. But then what is
the advantage of using existential types ? It just looks like more
work compared to the standard version that also makes use of
polymorphism. Or am I missing something ?

2. Through typeful heterogeneous collections

This technique is described at
http://homepages.cwi.nl/~ralf/OOHaskell/ and is able to bring most OO
principles into Haskell. This seems to be a very good and thorough
attempt. Unfortunately it looks more like a huge hack than a solution.
The problem I have with it is the awkward syntax it requires, which to
my newbie eyes doesn't look like Haskell anymore.

3. Through phantom types

I couldn't find any idiot-proof documentation on this topic but this
technique seems to be used to model inheritance. The few papers I've
come across (http://research.microsoft.com/Users/simonpj/Papers/oo-haskell/overloading_conf.pdf
,http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf ) seem
very interesting but all go way over my head.

4. Through O'Haskell (http://www.cs.chalmers.se/~nordland/ohaskell/)

Which is a non standard extension of Haskell that seems to be dead anyway. 

5. With this : http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf

This is a very interesting paper, at least for a newbie like me who's
used to Java.
The aim of this paper was to develop a same application in both Java
and Haskell and to compare the resulting implementations afterwards.

What interested me in this was the mechanism they used to model
inheritance (described on page 16 & 19), based on data types instead
of classes. The idea being that all constructors of the Employee
datatype have a same parameter, 'inCommon', of type
The data type CommonOfEmployees consists of all the fields shared by
all types of employees. By then defining polymorphic functions that
only use the 'inCommon' property of any employee, they've managed to
instantiate these methods only once. My explanation must be horrible
to you but you'll certainly get it by reading their paper.
The Haskell source code can be found here

The conclusion I drew from my quick & early findings is that the
latest method is the simplest way to get inheritance in my programs.

I guess my question now is this : Are there other ways to achieve
inheritance in Haskell ?
Simpler techniques ? Or more accurate / comprehensive ? Would you have
pointers to useful resources ?

I apology in advance for the errors, false assertions, misconceptions,
confusions made in this document. I'm still learning Haskell. I'd just
like to get the most of it.

Cedric Paternotte

More information about the Haskell-Cafe mailing list