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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
