Alex Ferguson wrote:
>
> Kevin Atkinson and I argue about C++'s 'Cleaner more natural syntax':
> > 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. There are also some things I can't do in C++ but really wish I
> > could, I also wish I could do those things with Haskell. I am not
> > saying C++ is an elegant language, however it is a powerful one. I
> > would like to have that power in Haskell.
>
> I concur that there are places, due to its desire to maintain
> strong typing properties that Haskell is 'less powerful' than C++.
> But the consensus seems to be that strong typing is worth the
> occassional pain (or at least we avoid the pain by not using Haskell
> if the task isn't well-suited, perhaps), and that we _don't_ want
> to abandon that in favour of C++'s inherent lack of type safety
> (or that if we do, we go and write C++ programs). Yes, there
> are areas in which it appears to be possible to make Haskell-style
> typing more general, without any basic loss of typing properties,
> but as you say in a related context, it rapidly gets Rather
> Technical, so the issues aren't as simple as 'Haskell's type
> system should immediately be made to accept everything C++ would'.
I never, ever, said that I would like Haskell to be able to do
everything C++ can. I also never said that I want Haskell to become a
more type unsafe language. If it was implied I'm sorry. What I did say
that I would like Haskell to support true ad-hoc overloading which you
seam to bitterly oppose to spite its many benefits.
Also, I strongly belove that if Haskell's type system is made more
powerful it can be suited to a great number of tasks. The only thing it
won't really be well suited for is low level system takes as those by
there very nature require unsafe casts of raw memory. However with some
low level extensions to be able to read and write to raw
memory--probably encapsulate with in a state monad of course--Haskell
could also be suited to those tasks. However that is not really what I
am interested in.
I am interested in using Haskell to come up with a really generic set of
containers and libraries. Haskell type system in its current state is
not well suited for this task at all. However, I fell that once it can
do this task it will be able to do it better than any other language out
there due to its type class system.
> > Haskell for *most* things has far cleaner syntax than just about any
> > other language out there. However, OO is not one of them.
>
> "OO" is such a open-ended term, with such a lack of any simple
> definition that I think it'd be best to avoid it entirely (I mean in
> this sort of discussion, though 'ever' wouldn't be a bad plan either),
> in favour of more specific, albeit more open-ended, features of same,
> whether those be message-passing, ad hoc polymorphism, subtyping,
> inheritance, state encapulation -- et cetera, et cetera. Haskell takes
> a decidedly 'cafeteria' approach to that shopping list, so blanket
> statements like 'Haskell is good/bad for OOP' obscure more than they
> reveal, IMO.
Ok here is my partial list.
- True ad-doc polymorphism
- Built in dynamic typing system.
- State Encapsulation
- A solution to the abilities arising from multi parameter type classes.
- Syntactic sugar for supporting OO programming styles
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
