[Haskell-cafe] Haskell's overlooked object system: was OO idioms redux

Ralf Laemmel Ralf.Laemmel at cwi.nl
Wed Oct 13 17:55:56 EDT 2004


Ben.Yu at combined.com wrote:

>Some people say that ocaml's object system is kinda useless. The best
>support I hear so far was:"it does not hurt"
>
Why do you (or do these people) think having all the OO idioms of OCaml
(see OCamls OO tutorial) is useless? Or do you mean too baroque? If not, 
what's
missing?

>implementation inheritance, the strange "#" syntax, virtual method, why do
>I need them?
>
Fine with me.
OOHaskell doesn't need them, indeed.

>In Java, people are doing programming-against-interface, implementation
>injection etc. All these show that we don't need implementation inheritance
>to be OO, and implementation inheritance is in many cases bad practice
>anyway.
>
Well having no implementation inheritance in Java would be a pretty 
brave limitation.
Anyhow, OOHaskell (and OCaml) has programming-against-interface as well.

Some related snippet from the OCaml tutorial.

{-

A point and a colored point have incompatible types, since a point has no
method color. However, the function get_x below is a generic function 
applying
method get_x to any object p that has this method (and possibly some others,
which are represented by an ellipsis in the type). Thus, it applies to both
points and colored points.
 
let get_succ_x p = p#get_x + 1;;
val get_succ_x : < get_x : int; .. > -> int = <fun>
 
get_succ_x p + get_succ_x p';;
- : int = 8
 
-}

The corresponding OOHaskell snippet

testp2 = do
          print "testp2"
          -- Note that 'mfix' plays the role of 'new' in the OCaml code...
          p  <- mfix (class_printable_point 7)
          p' <- mfix (class_colored_point 5 "red")
          do{ x <- p' # l_get_x; c <- p' # l_color; print (x,c) }
          let get_succ_x obj = obj # l_get_x >>= (return . (+ 1))
          get_succ_x p  >>= print
          get_succ_x p' >>= print
          print "OK"

>As somebody pointed out, we could do interface in Haskell with record. The
>only problem is names. If we could, as we can in OO languages, provide a
>separate namespace for the fields of each record. We are pretty much done.
>
Have you seen HList?
There are 4 different solutions for first-class labels in the distribution.

>The rest is some kind of record coersion+row polymorphism mechanism.
>
Yes, good point.
That's what we meant: the object system in Haskell has been overlooked.

>If haskell can do what Simon P. Jones and Mark Jones described in the paper
><<Lightweight Extensible Records for Haskell>>, I'd say it is a already a
>nice functional OO language.
>
It can readily do more than that:
http://www.cwi.nl/~ralf/HList

>Compared to Ocaml, 'OO' support is seamlessly integrated with the
>functional part. It leaves no redundancy, no overlapping in the language.
>
What are you referring to?
I mean: where is OO support seamlessly integrated with the functional part?
Do you refer to OOHaskell?

>In short, what if we don't create an object piece that competes with the
>functional part, but fix and enhance the record system that we currently
>have?
>  
>
... or just exploit heterogeneous collections.

Ralf




More information about the Haskell-Cafe mailing list