Kevin Atkinson wrote:
>
> On Tue, 5 Oct 1999, George Russell wrote:
>
> > Perhaps I'm being stupid. (It certainly wouldn't be the first time!)
> > But what does OO give me that I can't get with existential types (in
> > datatype definitions) and multiparameter type classes? The latter seem
> > to me much more powerful, since I can add dancing and singing methods
> > to objects without having to go back to the original class definition.
>
> 1) Dynamic types. You can't cast up.
You certainly mean to cast down (casting upwards corresponds to the
application of the existential constructor).
Down casts could be done. This would mean that each existential
constructor had to carry dynamic type information and there would be a
special pattern matching construct that checks this. One could argue
whether this feature is desirable or worthwhile in the presence of
parametric polymorphism and algebraic data types.
> 2) More specific types, you can't _easilly_ call the more general type.
> For example in OO this is very commen:
>
> class Base
> virtual foo()
> do stuff....
>
> class Derived, extends Base
> foo()
> call Base::foo()
> doo stuff
I guess what you mean by "more specific types" is inheritance. This is
not directly related to types, though. You are right, Haskell does only
provide a very weak form of inheritance, namely default methods. On the
other hand, many people consider inheritance a doubtful feature.
> 3) Encapsulation. You can't have private and protected members. Some
> of this can be done using modules. However it is more work.
Maybe, but I think it's good to have this separation of concepts:
classes provide a certain form of polymorphism, encapsulation is
something completely different that should be dealt with uniformingly,
i.e. by the module system. However, it would be nice if Haskell had a
more powerful module language.
> 4) Cleaner more natural syntax.
>From an abstract language point of view, there certainly is nothing
natural or even clean in having this special case syntax for the first
argument:
x.f y z
compared to
f x y z
In particular, it does not scale to methods where the first parameter
does not happen to be of the type to dispatch on (or where there
actually are zero or multiple such xs, cf. the binary method and multi
dispatch problems in OOP).
For certain problem domains however it might appear to be natural to
think in terms of objects that receive messages. But I'm not sure
whether this has to be reflected in syntax too much. Haskell is not an
object-oriented language. You can express most things that you can
express in OO languages but they will look a bit different. And
sometimes of course it will be more painful - but no single language can
be equally well-suited for every application.
> Unfortunately Haskell, like Java in some ways, is also a simple language.
Java is much more complex than most people realize. And Haskell is far
from being a simple language either. So adding even more features
requires compelling reasons, in particular, if there are already ways to
achieve the same effect without too much extra effort.
But of course, in comparison with C++ any language looks simple. ;-)
> I would like to be able to do the things in Haskell that I can do in C++
> but currently Haskell's type system is too simple to allow me to do
> them.
You are mixing up things a little bit. The Haskell type system
definitely is not simple. It is likely to be the most complex and
powerful type system of any major language around. The reason why there
are things that you can do in C++ but not in Haskell is that C++ does
not press typing that much. Templates for example are not really type
checked. That gives you flexibility at the price of safety or early
error detection.
Another aspect you mentioned in one of your postings is state. Again
this is not directly related to the expressiveness of Haskell's type
system. C++, like most other languages, simply ignores state in its type
system. So of course you won't have any problem as far as typing is
concerned. Haskell does capture the use of state in its types - being a
curse and a blessing.
Best regards,
- Andreas
