G'day all. On Fri, Aug 30, 2002 at 10:09:25AM +0100, Simon Marlow wrote:
Agreed that there are lots of inconsistent libraries out there, but why start a new project when there's already libraries@haskell.org? Surely this is the right point of focus for developing new libraries, and we also have a CVS repository for the code: fptools/libraries on cvs.haskell.org. We also have the beginnings of guidelines for naming conventions and coding style.
The short answer is that, speaking as a user of GHC and GHCi, I'd prefer to have libraries with mature interfaces "out of the box". Integrating experimental libraries too early inevitably creates a body of legacy code that I don't want to be responsible for. For example, for my part I've made a lot of changes in my version of Edison which are not backwards-compatible, which I believe are an improvement, but I still don't know if I've got it "right" yet. I don't want to break everyone's Edison code only to have it break again next release. Of course if the changes turn out not to require incompatibilities, there's nothing stopping me from submitting them, but had I been hacking fptools/libraries to begin with, I might have been more hesitant about playing with existing libraries in the first place. The long answer I won't go into in detail, but part of the problem is that being a fptools/libraries developer basically means having a GHC development environment. That requires an investment which I'm personally not able to make at the moment.
Really, it's not that hard - the only reasons I would actively argue against something going into fptools/libraries are: if there is duplication of functionality between libraries that will only serve to confuse users, or if there is substantial disagreement about whether a particular API is the "right thing".
...both of which describe exactly the situation that I'm in at the moment!
I see the process of standardisation as separate; at some point after the libraries have matured in fptools/libraries for some time, we will standardise some of them in a Haskell 98 addendum. This will probably be an ongoing process, with more libraries becoming standardised as they mature.
This raises an interesting question, because almost all newer libraries (certainly the ones I write) all use non-98 language features. I suspect that this is true of many new libraries, and certainly most of the "interesting" ones. Cheers, Andrew Bromage