Though I am _not_ exactly a Haskell expert, I could not avoid
commenting...
Kevin Atkinson wrote:
>
> Here is a laundry list of things I think Haskell still needs. By
> Haskell here I mean Haskell plus extension that are found in both hugs
> and ghc.
>
> 1) Support for true ad-hoc overloading. I am a *strong* believer that
> if the context is clear for a human than it should be clear to the
> computer. This also includes support for default parameters as found in
> C++.
"True ad-hoc overloading?" Unless you restrict it to dispatch on the
first argument, this would imply muliple-dispatch generic functions. In
fact, this is really what multiple parameter type-classes are all about.
So it's in there (well in the extensions, anyway).
Default parameters just don't make sense in a language that supports
currying.
>
> 2) Support for TRUE OO style programming.
What is "TRUE" OO style programming? If you mean objects with mutable
state, you're violating one of the most basic tenets of FP.
>
> 3) A better solution to all the unresolved overloading that comes up due
> to multi parameter type classes.
Many, if not most such difficulties associated with MPTC have to do with
the various numeric classes (Num, Fractional, etc.)...and this is
something that most definitely _is_ on the 'to-do' list, as I understand
it.
>
> 4) Being able to write
> do a <- getLine
> b <- getLine
> proc a b
> as
> proc getLine getLine
> and the like. I don't know the number of times that I get REALLY sick
> of having to explicitly bind everything to a variable. Monads do a very
> good job of supporting imperative style. Now lets make them less
> tedious to use.
ACK! For one thing this would mean that arguments would _always_ have to
be evaluated left-to-right...which is completely incompatible with a
non-strict language.
(actually, I've never been too happy with the 'do' notation myself, as
it to often obscures what's really going on...and I think what's really
going on is _important_)
Further, if you're going to mess with referential transparency, what's
the point? You might as well just use C++ (or, if things like pattern
matching are what draws you to Haskell, take a look at Pizza or GJava.
> 5) A rich set of standard libraries such as provided by the STL is C++.
...and they're on the way...not as quickly as anyone would like
(particularly the implementors themselves, no doubt ;-) )...
> And the points that are brought up so much that I don't even what to get
> into.
>
> 6) speed.
>
> 7) less memory.
A note on referential transparency:
One of the great potential benfits of an rt language--and one that at
least I believe will be more significant as time goes on--is the
potential for exposing parallelism. There have been some pretty cool
papers on the subject, and as multiple processor machines become more
and more common (as they no doubt will) the ability to parallelize at
run-time (because you needn't do extensive code analysis) will become
_terribly_ valuable.
> So what do you Haskell experts think.
Perhaps (and please take this as neither flame nor flame-bait) pure-lazy
FP just ain't for you! (just as it certainly isn't the right tool for
certain cllases of tasks).
Just my .02...
--ag
> --
> Kevin Atkinson
> [EMAIL PROTECTED]
> http://metalab.unc.edu/kevina/
--
Artie Gold, Austin, TX
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
"If you come to a fork in the road, take it." -- L.P.Berra
