Haskell 2010: libraries

[Simon Marlow]

This is more of a consistency issue than anything else.  We have to 
decide what to do with the libraries in the Report.

Right now, the Haskell Report specifies 15 library modules.  Things like 
Maybe, Char, IO, Time, and Random.  The situation is not ideal, for many 
reasons:

  - There are a lot more than 15 library modules available to Haskell
    programmers!  The libraries section of the report was a good
    idea when there were no libraries at all, nowadays it makes
    a lot less sense.

  - These modules are using the old non-hierarchical names.  Best
    practice these days is to use the hierarchical versions.

  - some of these libraries have well-known problems, and some have
    been superseded by better libraries: Time is a good example.

On the other hand, some people like having these modules around, and 
deliberately use them because they aren't allowed to change.

I'm mainly concerned with projecting a consistent picture in the Report, 
so as not to mislead or confuse people.  Here are the options I can see:

  1. Just drop the whole libraries section from the report.  The
     Report will still define the Prelude, however.

     There will be some loose ends where the rest of the report
     refers to entities from these libraries, e.g. the Prelude
     refers to Rational from the Ratio library.  We just have to
     fix up these references, moving the appropriate definitions
     into the Report as necessary.

  2. Just drop the obvious candidates (Time, Random, CPUTime,
     Locale, Complex?), leaving the others.

  3. Update the libraries to match what we have at the moment.
     e.g. rename List to Data.List, and add the handful of
     functions that have since been added to Data.List.  One
     problem with this is that these modules are then tied to
     the language definition, and can't be changed through
     the usual library proposal process.  Also it would seem
     slightly strange to have a seemingly random set
     of library modules in the report.

  4. Combine 2 and 3: drop some, rename the rest.

  5. Don't do anything.


Note that we have to take into account the FFI libraries too: the FFI 
addendum includes modules such as Foreign, CForeign, Storable, 
MarshalError, and so on.  The same issues apply: the report needs to 
mention some of the types and entities exported by these modules.

I'm tending towards (1), mainly because it provides a clean break and is 
likely to be the least confusing for users: they have one place to go 
looking for library documentation.

Please keep discussion focussed: this is about how libraries are 
presented in the Haskell report, not about library standardisation in 
general.  I'm aware there are much wider issues, but we have some 
immediate problems to address.

Cheers,
	Simon