1/24/2013

The Objectsystem of Haskell - IORef

Each second or third month, there pops up a new discussion on Haskell and Object Oriented Programming (OOP) in the blogs and mail threads. Usually typical questions are: "why does Haskell don't have it?", "what are the differences between the type classes and OO classes?", "how can non mutal state be incorporated in a design and combined with OO?" and similar ones.

After a while this discussion then is decreasing in intensity and most of the time the historic references are also cited like OOHaskell from Oleg Kiselyov, Ralf Lämmel, and Keean Schupke or O'Haskell from Johan Nordlander as another one. Sometimes non-Haskell examples from OCaml, Clojure, Scala and F# are given (you may name additional ones). And in rare cases a discussion spins of about functional reactive programming (FRP) being a paradigm used for more complex simulation situations, a domain, where OOP excells.

But actually, the fact that there is still no in-use OO extension of Haskell and that there is still a big difference between Haskell and other more cross-paradigm languages gives a hint that there might be more deeper reasons behind this missing link. There must be something fundamentally different between Haskell concepts and OO language concepts and this difference may also reveal interesting things about OO and Haskell itself. And actually of course this difference has been pointed to by many others and and is around the handling of state in general.

In this blog post I want to focus on this state handling and connect it with a statement on OOP which might be overdrawn but which is actually a hidden truth behind OOP:

One of the main reasons why OOP was and is successful is simply due to the new possibility of administering big amounts of state in a complex program in a reasonable and efficient manner. This is the core feature of OOP, which made it successful, nothing else, not inheritance not encapsulation nor re-usability.
In OOP this management of state is done by pointers to individual, identified, mutuable data blocks. Therefore one could argue that the OOP features of Haskell are named IORef and fclabels because those are the basic technologies in Haskell that allow programming with the same paradigms as used heavily in OOP: reference semantics instead of value semantics, whereas fclabels serves as an efficient and usable record system to make administration even easier.
The Objectsystem of Haskell is named IORef!
Of course this neglects all the other nice features of OOP like encapsulation, inheritance, re-usability. But let's go one step back: are those features not just enablers of making the basic fundamental use case working and isn't this fundamental use case the typical OOP state handling paradigm? Taking this approach further it becomes clear why OOP is not used in Haskell. This language puts a much more clean focus on state and in cases where complex state systems are needed (as in simulations for example) other solutions are taken by the Haskellers, like Monads, Arrows, FRP, which are keeping the value semantics. An actually could'nt we go without IORef in Haskell and only use a good record system and keep value semantics. Yes, of course but then it's not OOP any more. So to finalize with a last statement.
The discussion if it is OK to use IORef and the discussion if it is good to use OOP are actually identical.