[Haskell-i18n] SourceForge Project Active
Andrew J Bromage
ajb@spamcop.net
Sun, 1 Sep 2002 15:51:08 +1000
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