Arthur Gold wrote:
>
> 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).
Yes but often putting things in type classes is tedious to do. I also
want to be able to overload not only on the TYPE of parameters but also
on the NUMBER of parameters. It IS possible to do these things and it
DOES make sense in a curing system.
> Default parameters just don't make sense in a language that supports
> currying.
If overloading based on the NUMBER of parameters makes sense so does
default parameters as default parameters will just be syntactic sugar.
See http://www.dcc.ufmg.br/~camarao.
> > 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.
No. I mean being able to do things such as.
Have a collection of object of a common base class AND be able to up
cast them when necessary.
Be able to override methods and ALSO be able for the overriding methods
to call there parent methods.
I believe Haskell CAN do these things however the solutions are anything
but elegant.
> > 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.
NO. NO. NO.
proc getLine getLine will be interpreted as the do notion above. With a
powerful enough type system it WILL be possible. I will go into details
later if anyone is interested.
> (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_)
Maybe however it CAN be tedious.
> 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.
Your missing the point.
> 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.
I agree with you here. You just need to get the word out as WAY to many
people don't release it (with half of those people not even knowing what
a functional programming language is)
> > 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).
But with some work it CAN be.
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
