Just to clarify: the intent of the OOHaskell paper is to show that Haskell, *as it is*, already has an OO system that is at least as powerful as that found in C++, Java, Eiffel, OCaml. Actually, it is strictly more powerful than the OO systems of C++, Java, Eiffel. In OCaml, the Object system is an extension, with its own extensive syntax and _quite non-trivial_ type system. We show that we can do the same in Haskell without any extensions, and roughly in the same syntax (that is, modulo the usual syntactic differences between non-OO OCaml and Haskell). It is not our intent to pass judgment as to whether an implementation inheritance or multiple inheritance are good or bad. We merely want to show: - if you want implementation inheritance, here's how you do it in Haskell, roughly in the same syntax as in other OO languages, and with the same semantics as in other OO languages - if you want interface inheritance, here's how you do it in Haskell, roughly in the same syntax and with the same semantics - if you want multiple inheritance, here's .... - if you want open recursion and selective closing of open recursion, here's ... Ditto for virtual and private methods, objects in ST monad, overriding, polymorphic classes and methods. I'd really like to hear if there are OO buzzwords we have missed... Again, we do *not* propose to extend Haskell in any way. We do not need to introduce special subclassing and subtyping judgments into the type system, deal with co- and contra-variance and the implicit weirdly-typed 'this', etc. The existing typechecker does all this for us. Our aim is to clarify the relation between object systems and typeclasses, to clarify various, often quite baroque, OO type systems, and provide a lightweight library and a set of guidelines to let one play with an OO of their preference using existing Haskell implementations. You can use as many or as few OO features in Haskell as you wish.