(On a more serious note,)
I agree with the numerous people who support the inclusion of (in order from
most essential to least) multi-parameter classes, state threads,
standardization of concurrency features and foreign language interfaces.
For at least the first three of these, I think they should be in the final
standard NOT because a language is unusable without them --- after all,
`usable' languages like C and C++ don't have a standard way of handling
threads either --- but rather because they fit in naturally in the context
of Haskell. In other words, Haskell is expressive enough to accomodate
satisfactory, more-or-less platform-independent definitions. For example,
in the case of concurrency, at least, I think it is a much more natural
addition to Haskell than it is to Java. The concurrency combinators
can be defined semantically in terms of monads (as in Concurrent GHC) in
Haskell, whereas in Java it has almost nothing to do with any part of the
language besides a single keyword, `synchronized'. The same goes for
state threads, and I think nearly everyone agrees that multiparameter
classes ought to be added.
But we have only one revision left to include all these things.
I understand the motivation to standardize, and I think it is probably
a worthwhile thing to do, but, in the face of all these as-yet-absent
features, wouldn't it be better to postpone it? I am beginning to
feel like this was rushed along.
John said that he thinks we understand multiparameter classes well enough
to include them all in one go. I think he is basing this on our experience
with them in Gofer and the work Peyton-Jones, et al. did on the
possibilities for extending the type system. OK, but even if we know the
semantics well enough to be absolutely sure that we can get it right in
one revision, what about the library? There has been some work in this
regard (e.g., "Bulk Types with Class") but I think it is not unreasonable
to anticipate that the added expressive power of multiparameter classes
will have a _big_ impact on the structure of the standard library, and
I'm not sure at all if we can expect all the kinks to get worked out
without seeing it in action for a while. Gofer never had a big enough
library --- it hardly exploited the power of Gofer's classes at all ---
for us to use it to foresee the waves this might cause.
I have no problem at all with pursuing more advanced features in a future
language, Curry or Mondrian or whatever, but if we are going to freeze
Haskell, I think we should bring it to its natural conclusion first.
And frankly I don't think it's there yet.
-- FC
