On Tue, 5 Oct 1999, Kevin Atkinson wrote:
> In case you have not figured out a couple of months ago I posted the
> beginnings of a generic container and algorithm collection for
> Haskell.
This is exactly the sort of thing that OOP tends to be rather bad at.
How many times have I written in Java
SomeType x = (SomeType)( a_vector.getElement( i ) ) ;
thus relying on run-time type checking?
C++ is an improvement because of its template mechanism, but of course,
and I hope all will agree, dispite being a part of C++, there is nothing
object oriented about that. Now the problem with C++'s templates is that
they are just fancy macros. E.g. if you write template code that uses =
on objects of a parametric type, you might assume that = does not throw an
exception and have bugs when it does. To put it another way, the writer
of template code can not express enough restrictions on the types their
code may be applied to to guarantee that they are writing bug-free code.
ML and Haskell represent two approaches to doing "templates"
right. Each has their advantages, but both seem to be clearly
superior to the OOP approach. ML's functors offer a typed version
of C++'s templates. Haskell, in a sense, adds convenience by making
the instantiation the template code implicet. With that convenience,
there seems to sometimes come a price, which I think you allude to
next.
> During the process of doing that I discovered the many
> limitations of Haskell current type system. I simply could not do what
> I wanted to do in Haskell with out resorting to hideously complex
> types. The biggest thing that was biting be was all the ambiguity
> caused from using multiple parameter classes.
>
> If there is enough interest I could repost this code as well as an
> explanation of the many "hacks" I had to due to get around ambiguity
> arising fro the use of multiple parameter classes and other
> limitations of Haskell.
Rather than repost all the code, could you post just enough to show the
source of the difficulty?
Cheers,
Theo Norvell
