Packages in GHC 6.6

[Peter Tanski]

Simon,

>>    ... At the moment,
>>    the only packages you can add in this way are:
>>
>>      ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi,
>>      fgl, haskell-src, html, mtl, network, parsec, time, xhtml
>
>  ... instead include smaller and more "fundamental"
> packages: ByteString, regexps, Collections, Edisson, Filepath, Time,
> networking, web.

I agree with your original idea and Bulat's: the libraries packaged  
with a compiler should, as a general rule, be those that support the  
core features of the language or usage of the language itself.  Not  
far off from that are things like being able to work with the  
operating system--these are essentially related to I/O--because  
without them your machinations would only be able to operate on  
themselves.  Without getting philosophical about what is and is not  
necessary for a language to "speak," I'm just looking at the general  
big-libraries packaged with mature languages like Ada and C++.  So  
here is my vote:

Top priority: those you already mentioned, with Bulat's vote for  
Edison, ByteString, Filepath and Time; I vote for fgl (in my  
experience fgl is as useful in its own way as Data.Map), mtl, and  
haskell-src.  So the core list might be:

*base, haskell98, template-haskell, stm, mtl, haskell-src,
*ByteString, Edison, fgl --only because for Edison and fgl there are  
no reasonable alternatives, so these are in a sense "standard"
*readline, unix, Win32, Filepath and Time (they really complement  
unix and Win32)

*Cabal--though this is an extraordinary convenience, it is not  
strictly necessary (Haskell-GHC users could always be forced to  
Include everything outside of a standard system directory.  I don't  
mean a GHC-system directory--there are far too many language-specific  
directory structures crawling around, it's like trying to hide from  
Wal-Mart.)

... well, that's how I had started the email, but I think your  
original idea is right: stick with only what you absolutely need and  
with what is part of the Haskell "standard" library:


*base, haskell98, template-haskell, stm, mtl, haskell-src and Cabal  
are fine; the rest can go together in a special "distribution."


Why add mtl and haskell-src?  Those seem to be situations where you  
would have to install a specific library (mtl, say) and specially  
integrate it into your build of another.  At some point the  
dependencies merit the adoption of a "standard."

Extra-Haskell parsing is a good example of leaving things out.   
HaXml's parser (HuttonMeijerWallace, PolyLazy) is roughly  
interchangeable with Parsec in many ways--though reasonable people  
may differ on which is actually better--and installing or  
uninstalling either would be easy.

Things that are missing... There are some library systems that really  
should come standard and therefore need development.  The most  
specific I can think of are deep-core Haskell debugging libraries  
(would you think of grabbing gcc without gdb?)--a GHC "HAT."  Things  
that allow specialised code such as haskell-src-exts's dynamic  
loading modules would also be good--this is like having dynamic  
libraries for Haskell.

Sorry for the length; I've been literally bugged-out with getting a  
commercially and GPL-usable comparable replacement for GMP going...   
Personally I would love to give GHC a built-in interface to a real  
high-level math library (vectors, arbitrary-precision Reals?) but  
that would be as bad as forcing all gcc users to uninstall a  
hypothetical gcc-BLAS before they could install their own system- 
tuned or more precise library.  I have been realising more and more  
that Integers are not a math-library but a data-type (hence bitwise  
operations).

-Pete