Packages in GHC 6.6

[Peter Tanski]

Hi Bulat,

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

Sorry about that.  I put the emphasis on your mention of  
"fundamental," almost to the exclusion of compiler-builds.  My point  
was that there are two design considerations when you are designing a  
compiler system: (1) the compiler itself (which practically everyone  
agrees should optimally be stand-alone); and (2) the core language  
libraries.  Domain-specific languages like Mozart, research languages  
or languages with only one compiler, such as Clean, and languages  
which lack good FFI support tend to be complete language packages.   
Relatively mature languages such as Fortran, C, C++, Ada and ML  
(smlnj, MLTon) have "standard library" systems; I think Haskell is  
moving in that direction.

The library systems in Haskell have gone beyond the Haskell98  
standard of "core" functionality with extensions, such as GHC- 
specific code (and libraries integrated with it), TH, MTL and  
Arrows.  What is "standard" is more properly a matter for Haskell- 
prime but may (and has) been implemented into Haskell compiler  
systems, especially the "biggies," GHC and nhc98.  As compilers  
become more plentiful organisations and even individuals may move  
away from the Microsoft/Borland/CodeWarrior core distributions and  
introduce their own separate compiler for a language, such as Intel,  
Sun and IBM have for C, C++ and Fortran; Comeau and Digital Mars for C 
++; and many others.  Haskell hasn't gotten that far yet--once JHC  
and Yhc are production ready they might fill that position.

> 2. For windows-like OSes where users prefer to see larger monolithic
> installations we should include more libraries in "standard
> distribution".

I seriously believe the reason for standard distributions on Windows  
is the extreme difficulty of getting things to build correctly and  
work together.  Once you have reached that beautiful point where  
almost everything is balanced and relatively stable--Quick! package  
it before it breaks again!  Package distributions for OS X and mostly- 
GUI Linux distributions are a convenience; they aren't practically  
necessary as they are with Windows.  Imagine trying to tag GHC  
distributions to a capricious system like MinGW--which may have older  
versions of gcc installed.

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

--web/networking?  When I first wrote that email last night I agreed  
with you that including web and networking tools would be good, as a  
kind of uniform-interface to varying low-level systems libraries, but  
these are the kinds of libraries that are easily installed separately  
from a distribution and may be volatile enough to merit separate  
update cycles.  For HTML, XML and cgi-networking in particular there  
are several stand-alone, stable libraries too choose from.

> i think that this are the kinds of libraries most widely used.
> ... 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

I agree.  Utility is, however, a very relative term.  Core language  
systems such as general Haskell-tuned data structures is not because  
at some point all programs need them to function.

> 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

Separately maintained, of course; that would give some freedom to  
Porters :)

> and last - all the libraries installed except for core ones will be
> easily upgradable without upgrading ghc... boost their
> development.

That is the hope, I guess.  The unfortunate problem with Haskell is  
rampant, rapid bit-rot: some programs written or maintained into  
2003---only three years ago!--are already outdated.  GreenCard is a  
prime example of this.  My point in emphasising a somewhat standard  
compiler-and-core-libraries setup was to encourage widespread support  
and maintenance of "new-standard" libraries and to ensure that by  
forcing the compiler to build with them, they would not be left behind.

-Peter