[Haskell-cafe] Thoughts on Haskell and OOP
Kevin Van Horn
kevin at ksvanhorn.com
Thu Jan 1 19:28:21 EST 2009
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/59a3825b/attachment-0001.htm
More information about the Haskell-Cafe
mailing list