Mark,
Out of curiosity, how big is the user community? How many downloads of
the software? How many are on this list? If you figure that 1 user in
1000 is actually going to contribute a useful change each month (that is
probably optimistic), the slow flow of changes isn't that surprising.
Also, why are there so many Haskell compilers for so few users?
There is really only one PD C compiler, GCC, and only one PD Perl
interpreter, perl (or vice versa on the capitalization).
Haskell has Hugs, GHC, NHC, HBC, for the core language, plus
there are derivatives like ....cayenne, clean, mercury, etc.
The variety of implemetations probably fragments the user community
excessively further inhibiting growth.
As far as fixing error messages go, it is hard for users to do that
because they don't know enough about where the type system is going.
My guess is that there is a big tradeoff between powerful type systems and
clear error messages. Didn't Haskell98 eliminate monad comprehensions
and give lists a special syntax so beginners could understand error
messages. (To me, this seems like a step in the wrong direction)
The rewards for fixing stuff in haskell implementations are further
reduced because compilers don't feel all that modular and because changes
to the typesystem can obsolete large classes of fixes (especially to the
error reporting system).
For example, if Haskell moves to a Categorical Prelude with Arrows as a
library interface standard and extensible records, users will be
interacting much less with the language and much more with generic library
interfaces. In that context users will rarely use Data statements
or raw constructors and work involved with cleaning up those error
messages becomes less useful (I assume the language developers know this
as well and that is why they are not putting effort into the error message
side of things).
As an aside, the cost of this very powerful type system will probably be
error messages that are probably incomprehsible to those not versed in
category theory (I think the cost is worth it, C++ and Java has similar
issues with OO theory).
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-212-697-0184 voice The Easiest Way To Shop
On Thu, 19 Aug 1999, Mark P Jones wrote:
> | 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
>
