Quite a lot of discussion has concerned standardization in the sense of
standards bodies --- in fact I'm a little sorry we used the word `Standard'!
Perhaps we should have called the fixed design `Haskell Omega' instead! What
we're proposing is simple to make one more revision --- call it Haskell 1.5 if
you like --- and then not to make any more. It's nothing to do with standards
bodies, government contracts or whatever. The problem `Standard Haskell' is
trying to address isn't to attract new industrial/government users who won't
touch anything without an ANSI stamp on it. It's to make life easier for the
people who already use Haskell: teachers, text book authors, researchers, and
of course industrial users who are not so bothered about official
standards. Take me personally for example: I couldn't care less if the
language I teach is officially standardised or not, but I do care if my notes,
program libraries and example programs become obsolete every time I teach my
course!
Official standardisation is a different problem, with different goals. Someone
else is welcome to take that up, preferably after our committee has finished
its work, but I'm not going to.
The point has also been made that Haskell 1.4 lacks some features that are
already quite well understood and will be sorely missed for serious
applications --- multi-parameter classes, state threads, existential and
universal types. If this is the last revision then the most important
extensions must be considered now; they can't be deferred until the next
version. I'm well aware of that, and I think the rest of the committee is
too. Extensions are not ruled out: nevertheless I think it's right that we
should approach such matters in a restrictive spirit. The last thing we want
to do is add experimental features to `Standard Haskell', only to find out in
a year's time that we got the design wrong. It seems to me that the three
points above probably are sufficiently well understood for us to get the
design right now; other ideas like interaction with other programming
languages probably are not. However, I don't want to pre-empt the committee's
work here by saying in advance what will go in and what will not.
John Hughes
