| So generally there is a conflict between making the language better
| and keeping it compatible. Probably indeed the only solution for now
| is to ensure that libraries are being ported to current tools and
| that their state wrt. this process is clearly marked.
Yes, there is clearly such a conflict. What not everyone may know, though
is that the Hugs/GHC federation, with much help from others (e.g. Chris
Okasaki)
have been making strenuous efforts to build a set of libraries that work,
are documented, and remain in that happy state. You'll find the
documentation
at
http://haskell.org/ghc/docs/latest/set/book-hslibs.html
These libraries are currently rather unromantically called "hslibs".
Better names welcome!
The hslibs libraries come with each release of GHC, and we compile them
with the current GHC every night, so at least they continue to compile.
The better-engineered ones come with a bunch of tests that we run too.
What this means is that at least these libraries should work despite
changing language definition and GHC versions.
hslibs is not part of GHC, though. It's intended to be a *Haskell* library
not a *GHC* library. Andy Gill has made a significant fraction of hslibs
work with (STG) Hugs. The current implementations predate the Haskell FFI,
and so are more GHC-specific than they should be, a situation that we
hope to improve, incrementally. (Any offers of help?)
hslibs isn't a "closed" library. Anyone who wants to contribute a library,
and can convince us (not hard!) that it's a Good Library, can get write
permission
to the CVS repository that holds the code. They contine to "own" and
maintain
their own code. The Edison library is a good example; it's in the
repository, but
Chris Okasaki maintains it.
hslibs doesn't replace the haskell.org library page. The latter is very
free-form;
anyone can put anything there, and doesn't have to maintain it. hslibs has
a bit
of quality control; we try to avoid duplication (one of everything rather
than N of
everything); we don't ship code that no longer works; etc. I think all this
is a
step in the direction that various people in this thread have been
advocating.
Bottom line:
Writing and maintaining good libraries is a lot of work
We need to work together to do this
hslibs is a start in this direction
We would welcome more participation
Simon
