Looks like my worry is pointless. :->
I was just afraid that Haskell may pick up another object monster. (And I'm
a C++/Java programmer)
Although I still miss a simple primitive language construct to do
'extensible record', it is definitely a nice work both theoretically and
practically to present an OO library.
And I'm totally with you guys about 'leaving choices to others'. My belief
is: the more orthogonal, the better.
Cheers,
Ben.
Ralf Laemmel
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/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise the IT Security department at ITSEC@combined.com immediately