Priorities

[John Hughes]

For the last few days, my mail-box has been full of mail about the M-R, 
lazy pattern
matching, n+k patterns, comment syntax--it's just like the good old 
days! And that
worries me.

Each of these topics is a snake pit--a tricky area of language design, 
with many
alternative possibilities and no clear winner. As such, they make great 
discussion
topics--if you want to start a heated argument, just propose a change to 
one of
these (mea culpa)! We've also been discussing most of them for sixteen 
years.

Of course, it's worth raising them from time to time, in case new 
insight means
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! 
That's
destructive. We shouldn't change these things unless we can very, very 
clearly
make an improvement.

The fact is, we've lived with the present design for over a decade in 
each case,
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 
experience
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 
solution--importing
         a different module--sucks.

    Monad transformers
       - dramatically simplify constructing new monads
       - not a language feature in themselves, but demand extensions to 
work well.

    Multi-parameter classes with functional dependencies
       - used everywhere... for example in monad transformers... so 
*must* be
         included this time
       - omitted from Haskell 98 because "the right design" wasn't clear
       - it's still unclear! Functional dependencies *in some form* are 
essential,
         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, 
we need
         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 
come?

I'd like to see clearer priorities and a more focussed discussion--maybe the
Wiki can be used to help?

John