Standard (core) libraries initiative: rationale

[David Roundy]

On Mon, Nov 27, 2006 at 10:28:09PM +0300, Bulat Ziganshin wrote:
> [...]
> and this leads us to other question - whether this set and API of each
> library should be fixed in language standard or it can evolve during
> the time?...

To me, this is the deciding issue.  The Haskell 98 libraries have some
severe issues which are unfixable because they're defined as part of the
standard.  My preference for Haskell' would be to have a *reduction* in the
size of the core libraries.  For example, the Time and Locale modules are
pretty much useless, and totally unnecessary, since they can be easily
implemented in Haskell 98.

Yes, it would be nice to have at least a de facto standard set of
libraries, but this is best done apart from the language standardization
process.  This has worked reasonably well so far, and has mostly been
hampered by the limitations of Haskell 98, which mean that relatively few
libraries support the standard Haskell language.  I'd like to see work on a
standard set of libraries follow Haskell', with the libraries being written
in pure Haskell'.  The libraries defined in the standard should be limited
to those which are either universally used or necesary in order to
implement the rest of the libraries.

This question mirrors the base/core/whatever package question, of course,
and I certainly don't know best which modules need to go into the core set
of libraries defined by Haskell', but I'd like it to be minimal in the
sense that I'd like to not see libraries included that could practically be
implemented on top of the other libraries.  e.g. System.Process (if
sufficiently well-defined and/or portable) probably should go in, as those
functions are most likely impossible to implement in portable Haskell',
even with the FFI.

It'd be nice, though, to see some work towards a set of "standard" (either
de facto or otherwise) libraries developed to work nicely with Haskell',
once that exists.  But my guess is that it'd be best to wait quite a while
before setting anything in stone, just because it's so hard to get an API
right.
-- 
David Roundy
Department of Physics
Oregon State University