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