base libraries

[Bulat Ziganshin]

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 at gmail.com