Haskell has been around in one form or another for nearly two decades now, yet has never been extended with explicit support for object-oriented programming.  I've been thinking about why this is so.  I've come to the conclusion that Haskell simply doesn't need any explicit OOP support -- algebraic datatypes, modules, lazy evaluation, and first-class functions give you everything you need 

to do the kinds of things you would use classes and inheritance for in OO languages.

To see why this is so, let's think about what OOP is.  At the most basic level we have what some call object-based programming.  This amounts to support for data hiding and abstract data types.  Haskell's module system handles this function quite well, without any need to introduce a special concept of "class" (in the OO sense) nor private vs. public class members.

Object-oriented programming is then object-based programming plus class hierarchies and inheritance.  Why are these useful?

Properly used, OOP is all about interface inheritance, not implementation inheritance.  (At least in C++, implementation inheritance -- inheriting the data members and method implementations of a base class -- usually leads to bad design, and is discouraged by the experts.)  (For those more familiar with Python, "duck typing" is the analog of interface inheritance for a dynamically-typed language.)  Interface inheritance allows you to write procedures that operate on the base-class interface, but can be applied to objects of any type derived from the base class.  Can we do this in Haskell?

Yes, we can.  Let's consider the Haskell analog of an immutable C++ base class:

  struct Base {

    virtual ~Base();

    virtual int foo() const;

    virtual int bar(int n) const;

  };

  class derived :: public Base {

    ... data members ...

  public:

    derived(T_1 arg1, ..., T_k argk);

    ... implementations of the virtual functions ...

  };

Haskell has no direct analog of object classes and virtual methods, but you can use lazy evaluation and first-class functions to achieve the same result:

  data Base = Base { foo :: Int, bar :: Int -> Int }

  derived :: T_1 -> ... -> T_k -> Base

  derived a_1 ... a_k = Base { foo = ...; bar = bar } where bar n = ...

 

The analog of a mutable C++ base class is a little bit more involved, but not much.  Suppose that we change bar(int) to be a mutating method in the C++ Base class:

  virtual int bar(int n);

The Haskell analog then changes to

  data Base = Base { foo :: Int, bar :: Int -> (Int, Base) }

  derived :: T_1 -> ... -> T_k -> Base

  derived a_1 ... a_k = Base { foo = ...; bar = bar } where

    bar n = (..., (derived a_1' ... a_k'))

(Here a_1', ..., a_k' are k expressions involving n and a_1, ..., a_k.)

What do the rest of you think?  Is my analysis correct?