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
Hello Simon, Monday, November 27, 2006, 2:03:00 PM, you wrote:
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?
ok. just my library which you calls ghc-base there, is already named Core and even reported in HCAR :) how about naming this set as standard [Haskell'] libraries? it is our goal - develop set of libraries that will be included in any Haskell implementation
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.
while i can't say anything about readline and included it only because it's already in 6.6, other libs included because these are probably will be of general interest and help making Haskell programming easier and higher-level also, we have 10 array types in Base library :) so, inclusion of two monad transform libraries may also be possible if these provides different features
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.
I'm 100% agree. let's start with Ian's minimal set and discuss inclusion of other libraries which will be proposed. that we need to set up here, are the rules of decision and may be even some formal process/group about inclusion criteria. i propose the following: * BSD-licensed, and even belong to Haskell community? * portable (is sense of compiler and OS), may be just Haskell' compatible? * already widely used you also propose to follow rule * shouldn't duplicate existing core libs functionality i'm against this because new ways to do the same things appears, and in any important area there are alternative ways - say wxHaskell and Gtk2Hs libs. my POV is that we should provide libs that are in wide use. otherwise, we will create a strange situation. imagine that there is a lonely wxHaskell lib which has 1000 users and it's enough to include it in core set. there is also another GUI lib which also has 1000 users, that is enough to include it. but two libs together make inclusion of any impossible! may be there are some little differences that makes only first library acceptable for some users and only second - for other. we can't see these differences because we just consider both as GUI libs and want to include only one! in the same way we can't include both gzlib and bz2lib because both compresses data :) so, let's users decide. it's more important to have guidelines describing strong and weak points of each lib in order to make selection easier -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (2)
-
Bulat Ziganshin -
Simon Marlow