| Actually, I have fond memories of Algol compilers that gave error
| messages pretty much as comprehensible as those above.  I guess the
| problem is that Haskell compilers are prepared by people who have more
| pressing tasks than repeating old work on user friendly error messages
| :-(

Jon's comments bring up an issue that's been on my mind
for some time now.  Although this isn't a direct reply
to Jon's message, I think it might still be a good time
to raise the topic.

One of the greatest disappointments to date of the move
to more liberal (i.e. free software) licenses for systems
like Hugs and GHC, is that it has done almost nothing to
stimulate contributions to the implementations themselves
from outside the immediate (and small) group of developers
concerned.  Compare this, for example, with the Linux
community where the number of external contributors is
often cited as one of the benefits of the development
model used there.  Of course, it may just be the size
of our community, and the subject area: there's a much
greater demand for operating systems than there is for
lazy functional language implementations, and there are
probably a lot more people with expertise in the former
than there are in the latter.  And we shouldn't discount
or forget the valuable contributions that quite a lot
of people already make to Haskell in other ways, by
answering questions on this or related lists, by using
Haskell to build interesting applications, and so on.
What I'd like to do is to stimulate more in the way of
contributions to the implementations.

So perhaps we should be more explicit: I'm sure that all of
us involved in developing Haskell systems would welcome
contributions from the community that will help to make the
tools better.  Better tools will benefit the whole community,
and will make them accessible and useful to a much wider
audience.

This doesn't mean that people shouldn't post bug reports
or gripes about the systems --- the poster may not know
how to fix the problems, but perhaps their message will
inspire somebody else to tackle it.  But I do think that
we need to move away from a "them and us"/"developer and user"
picture, and towards a more community oriented "us".

All the best,
Mark



Reply via email to