Hello Simon, Friday, November 24, 2006, 1:58:36 PM, you wrote:
There are several interconnected issues, which makes this hard to discuss on a mailing list.
i hardly imagine how it can be discussed on wiki :)
thanks, it's much closer to my POV. still some problems exists. first, this proposal don't realize problems with upgrading libraries used by Cabal itself. is it possible to have, say, base 2.0 and 2.1 installed side-by-side and make Cabal import just base 2.0 against which it was written? second, rules for ghc-specific libs pops up as some modification of initial rules, it will be better to include them in general rules themselves. third, this don't split core libs into the pre-installed and installed by package manager. so, my updated proposal: Now Haskell standard libraries (as specified in H98 Report) are very small and old-fashioned, it's impossible to develop real programs using this API. In order to facilitate Haskell-based development, we need a much wider, not-fixed set of libs which are guaranteed to be available with every Haskell compiler. libraries should be split into 4 rings: frozen, core, base and the rest * frozen libs are installed with haskell compiler and cannot be upgraded using Cabal. it includes Cabal itself and libraries required by Cabal, currently it's the Base library. compiler may provide its own ways to upgrade these libs * core libs are tied closely to specific compiler and version. therefore, these are also preinstalled but can be upgraded with Cabal. in order to make upgrading not-a-headache, version of such library must include compiler version, i.e. TH 6.6.0. for ghc these currently includes TH and STM libs * base libs are *guaranteed* to be shipped with any haskell compiler (compliant with this proposal). these libs are installed using Cabal or OS package manager, only on poor Windows-like systems these should be included in monolithic compiler distro. the reason is to allow user to got latest, bug-fixed versions of these libraries for the installation moment these libs should include rich set of functionality. criteria of inclusion library in this set are: widely used, small and portable. Portability: these libs should work on windows and major unix branches, on ghc/hugs/nhc and other proposal-compliant compilers, otherwise we can't guarantee availability everywhere. It should be easy for porters to prepare such lib for their systems Widely used: this should include data structures, general data processing, other things that facilitates development in general as opposite to solve some particular problem. plus basic OS interfaces. haskell98, readline, unix/Win32, QuickCheck, fgl, haskell-src, html, mtl, network, parsec, time, xhtml, ByteString, regex-*, Edison, Filepath, MissingH, NewBinary, arrows, HUnit, QuickCheck, monads it should be great also to strip down size of HaXml lib and include it here. now it don't conform only to size criterion * there are also other great libs that are either too fat or os/compiler specific, such as gui and database ones. these can be included in some distros or downloaded and installed separately using Cabal infrastructure there are also a number of Cabal-specific problems we should solve: 1) libraries required by setup scripts (Setup.hs) should be specified as dependencies in .cabal file: Build-Depends: FilePath this way, the library will be installed just before running Setup script. of course, all the Build-Depends libs should be made available for setup script 2) cabal, cabal-get and other package management tools should use only libraries from frozen set. any extra functionality required (networking, file management...) should be *copied* into these packages. this just means handmade instead of automatic dependencies tracking, but we can't rely on automatic management for tools that implement this management! (this proposal don't include some topics, like testing and Hugs, where i can't say anything new compared to Simon's page) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com