rjmh at cs.chalmers.se
Thu Feb 2 05:38:07 EST 2006
For the last few days, my mail-box has been full of mail about the M-R,
matching, n+k patterns, comment syntax--it's just like the good old
days! And that
Each of these topics is a snake pit--a tricky area of language design,
alternative possibilities and no clear winner. As such, they make great
topics--if you want to start a heated argument, just propose a change to
these (mea culpa)! We've also been discussing most of them for sixteen
Of course, it's worth raising them from time to time, in case new
we can find a solution that is clearly much better than we found before. But
the risk is that we go over the same old arguments, perhaps the consensus
is slightly different this time, we make a change to the language, and who
knows, next time the language is revised, maybe it'll change back again!
destructive. We shouldn't change these things unless we can very, very
make an improvement.
The fact is, we've lived with the present design for over a decade in
and we can live with it for another decade if we have to. The problem with
Haskell 98 is not its warts--it offers a very pleasant programming
despite them. The problem with Haskell 98 is that it *lacks* features which
have become absolutely essential to Haskell programmers today. Those
features are what really *need* discussion and energy spent on them.
What are the top priorities for inclusion in a new standard? How can we
identify them? I have some personal favourites, of course:
ST state threads--absolutely essential.
- but how to distinguish strict and lazy state? The present
a different module--sucks.
- dramatically simplify constructing new monads
- not a language feature in themselves, but demand extensions to
Multi-parameter classes with functional dependencies
- used everywhere... for example in monad transformers... so
included this time
- omitted from Haskell 98 because "the right design" wasn't clear
- it's still unclear! Functional dependencies *in some form* are
but associated types and datatypes look nicer in many ways!
- is it too late, in practice, to replace fundeps by something
else? How will
we know? If we are to standardize on associated types instead,
a major effort to *make sure* all important applications of fundeps
can be represented. How will we organize that?
Type system extensions--at least existential and rank-2 types.
- should we go further? How will we know?
My favourites may not be your favourites. How will we know what the most
important features to discuss are? Here's a thought:
Wouldn't it be nice if the most important Haskell tools and libraries, were
actually written in standard-compliant Haskell'?
One such tool is wxHaskell--named by 19% of Haskell users in my survey,
it's the de facto standard GUI toolkit. wxHaskell makes essential use of
existential types in its interface, a strong reason for including them in
Haskell'. It also uses multi-parameter classes and functional dependencies,
although much less heavily.
What other tools "must" be supported by Haskell'? What other extensions
must be present to support them? What issues remain before those
extensions are standardized, and thus frozen in stone for many years to
I'd like to see clearer priorities and a more focussed discussion--maybe the
Wiki can be used to help?
More information about the Haskell-prime