[Haskell-cafe] Haskell's overlooked object system: was OO
Ben.Yu at combined.com
Ben.Yu at combined.com
Thu Oct 14 10:44:55 EDT 2004
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.
<Ralf.Laemmel at cwi.nl> To: haskell-cafe at haskell.org
Sent by: cc:
haskell-cafe-bounces@ Subject: Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
10/14/2004 09:21 AM
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
> see myself using that framework in practice, in the form presented.
> 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.
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.
> 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
> 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 :-)
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
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 at combined.com
More information about the Haskell-Cafe