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

[Ralf Laemmel]

Graham Klyne wrote:

 > At 22:17 13/10/04 +0200, Ralf Laemmel wrote:
 >
 >> ... We reconstruct OCaml's tutorial in Haskell  ,,,
 >
 >
 > I think that's interesting as a theoretical exercise, but I don't 
currently
 > see myself using that framework in practice, in the form presented.  
As you
 > say "Simply syntactic sugar would make OOP more convenient in Haskell."

Just for clarity ...

As Oleg said, we would like to refrain from judgements regarding
- OO in general
- the urgency of combining all of OO with FP
- the urgency of the combination in the case of Haskell.

We have (varying) opinions about that ... but the OOHaskell effort is
about showing that Haskell readily comes with an object system, or the
ability to express it.

That's it!

At a more arbitrary level, we opted for an OCamlish object system
because OCaml's system is definitely a good benchmark in terms of the
many idioms covered. It is also a rewarding approach because OCaml's
relies on non-trivial language extension, where our OOHaskell approach
uses Haskell's existing type system to bring OO to Haskell.  This is
very, very rewarding for Haskell aficionados, indeed. We are also
looking at OHaskell, Haskell++ and others, whose publicaly available
examples should eventually become available for OOHaskell as well.

When we think of syntactic sugar then this is merely about keywords
such as class, interface, begin, end, method, ..., which some people
might ask for anyway.  With an OO hat one, people might want to really
"see" the different forms of absractions methods, mutable fields,
classes, mixins, while from an FP point of view functions and records
are totally sufficient. Anyway, some of these keywords can be provided
quite conveniently just as combinators. These combinators would then
perform additional type-level checks or they are just
NO-OPs. Personally, I wouldn't want any syntax extension.

To summarise, what's very important in our view is that OOHaskell
shows that no language extension is needed to bring OO to Haskell. And
even in the case where we end up providing syntactic sugar then this
is about surface syntax whose reduction to normal Haskell syntax is a
*local structural mapping* as it could be peformed by the most trivial
preprocessor or macro system. So the type system of Haskell is fit for
OO. That's cool.

 From a practical perspective, the foundation of OOHaskell to depend on
HList implies that type errors are potentially inconvenient depending
in turn on encoding details of the type-level code. For example, it
takes some coding effort to teach the type-level implementation such
that you see type errors that are anywhere close "class a found but
class b required" or "class a is not a subclass of class b". The HList
paper discusses some idiom for better type error messages in
type-level code. A mail by Oleg on keyword arguments discusses another
idiom, a CPS-like trick, but there is more work to be done.

 > It is encouraging to see that the OO structures can be constructed 
within the Haskell type system.

Absolutely.

 > Would it simplify your approach significantly to focus on non-mutable
 > objects?  (In recent discussions with a colleague who implements complex
 > systems in Java, he has observed that their systems are easier to 
understand
 > and maintain when they elect to use non-mutable objects.)

Again, we leave it to others to make choices. If we wouldn't present
the details of mutable projects, Haskell object system will be claimed
to be incomplete, which it is not :-)

Ralf

http://homepages.cwi.nl/~ralf/