Bulat Ziganshin wrote:
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
Please let's not change the terminology again. On the wiki page we use the term "Core libraries" for the set of libraries shipped or available on all the compilers. I don't see a good reason for naming any more sets of libraries, so can we just keep things simple?
haskell98, readline, unix/Win32, QuickCheck, fgl, haskell-src, html, mtl, network, parsec, time, xhtml, ByteString, regex-*, Edison, Filepath, MissingH, NewBinary, arrows, HUnit, QuickCheck, monads
So you want to have two variants of monad infrastructure, mtl and monads? How does the user decide which one to use? Two variants of HTML infrastructure? Why Edison rather than any other data structure framework? One particular non-portable line-editing library? Some of these choices seem entirely arbitrary. When there's an overlap and no clear choice, usually the right thing to do is let the user decide. At least until a concensus emerges. We have an effective mechanism for proposing library changes now, so I suggest that the Core libraries should start small, and then expand via proposals. That way we get to discuss additions one at a time, rather than throwing the kitchen sink in to begin with and having to argue about what to remove later (and upsetting users when we do remove things). This way We end up with a more consistent, well-design, whole. Cheers, Simon