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