On 18-sep-2007, at 14:10, Simon Marlow wrote:
Adrian Hey 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
Neil Mitchell wrote: 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. -- /\ / | arthurvl@cs.uu.nl | 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