[Haskell-cafe] Re: Building "production stable" software in Haskell

Arthur van Leeuwen arthurvl at cs.uu.nl
Tue Sep 18 10:00:05 EDT 2007


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.

-- 

   /\    / |       arthurvl at 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





More information about the Libraries mailing list