Packages in GHC 6.6

[Bulat Ziganshin]

Hello Peter,

Wednesday, August 23, 2006, 10:00:00 AM, you wrote:

>>>    ... 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.

> 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.

sorry, but you miscitated me and seems to misinterpret whole idea:

1. Simon suggests that there is a core GHC distribution. it should be
GHC _compiler_ itself and contains only libraries whose implementation
are closely tied to compiler version (such as template haskell) or
required to build ghc itself (such as regexp-posix). on the
package-friendly OSes it should be the only GHC distribution, with
intent that all other libraries required for compilation of concrete
program, will be installed automagically on demand


2. For windows-like OSes where users prefer to see larger monolithic
installations we should include more libraries in "stadrad
distribution". i suggested to exclude from list above graphics/sound
libs, i.e. leave only HUnit, QuickCheck, cgi, fgl, haskell-src, html,
mtl, network, parsec, time, xhtml and add more "fundamental" libraries:
ByteString, regexps, Collections, Edisson, Filepath, Time, networking, web

my main idea is that libraries i suggest to include is very small so
that they will not make installer substantially larger. the rule of
thumb is that libraries bundled should be much smaller that 'base' lib
and implements one of following

* data structures and algorithms (highest priority)
* web/networking
* interfacing with OS such as file operations (lowest priority)

i think that this are the kinds of libraries most widely used.
moreover, exclusion of large and useless graphics libs will allow to
cut down GHC installer by about 20%, while "selling" of basic ghc
without these libraries will not by for us any more size reduction


3. We can also create "larger installer" which includes libraries and
tools that also highly popular but too big to "sell" them to all who
want to download ghc. i mean at first place graphics, databases and
RAD tools. concrete, wxHaskell, gtk2hs, db libs, VisualHaskell and
EclipseFP


and last - all the libraries installed except for core ones will be
easily upgradable without upgrading ghc what will boost their
development. on the other side, when we upgrade ghc itself, it should
be possible to leave versions of these libraries that are already
installed


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com