On 18-sep-2007, at 14:10, Simon Marlow wrote:
Adrian Hey wrote:
Neil Mitchell wrote:
Hi
They are less stable and have less quality control.
Surely you jest? I see no evidence of this, rather the contrary
in fact.
No, dead serious. The libraries have a library submission process.
It does not follow that libraries that have not been submitted
to this process "are less stable and have less quality control". Nor
does it follow that libraries that have been through this submission
process are high quality, accurately documented, bug free and
efficient
(at least not ones I've looked at and sometimes even used).
Adrian's right - the set of libraries that are shipped with GHC is
essentially random. A bit of history:
Originally we shipped pretty much all freely-available non-trivial
Haskell libraries with GHC. At some point (about 5 years ago or
so) the number of Haskell libraries started to grow beyond what we
could reasonably ship with GHC, and some of them were providing
duplicate functionality, so we stopped adding to the set. We made
a few small exceptions (e.g. filepath) for things that we felt
really should be in the default GHC install, but to a large extent
the set of libraries that are "shipped with GHC" has remained
constant over the last 3 major releases.
In 6.6, we made a nomenclature change: we divided the packages
"shipped with GHC" into two: those that are required to bootstrap
GHC (the "boot" libraries, until recently called the "core"
libraries), and the others that we just include with a defualt
binary install (the "extra" libraries). On some OSs, e.g. Debian,
Ubuntu, Gentoo, you don't even get the "extra" libraries by
default. This was intended to be a stepping stone to decoupling
GHC from these libraries entirely, which is possible now that we
have Cabal and Hackage.
What I'm getting around to is that being "shipped with GHC" is not
a category that has any particular meaning right now. I think it's
time the community started to look at what libraries we have in
Hackage, and identify a subset that we should consider "standard"
in some sense - that is, those to which the library submission
process applies, at the least. If there were such a set, we could
easily make GHC's "extra" libraries equal to it.
Ofcourse, now we hit the situation that Eclipse is in as well:
everything worthwhile should be downloaded next to the base
functionality. This has lead to many slightly differing distributions
of Eclipse. The same problem occurs with Linux distributions...
I personally always liked Python's 'batteries included' approach.
Python comes with enough libs standard to be genuinely useful.
This, I think, is a good model from a marketing point of view.
With regards, Arthur.
--
/\ / | [EMAIL PROTECTED] | Work like you don't need
the money
/__\ / | A friend is someone with whom | Love like you have never
been hurt
/ \/__ | you can dare to be yourself | Dance like there's nobody
watching
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
