Haskell 2010: libraries

[Duncan Coutts]

On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote:

> 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:

>   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.

I'd advocate 4. That is, drop the ones that are obviously superseded.
Keep the commonly used and uncontroversial (mostly pure) modules and
rename them to use the new hierarchical module names.

Specifically, I suggest:

     1. Ratio		keep as Data.Ratio
     2. Complex		keep as Data.Complex
     3. Numeric		keep as Numeric (?)
     4. Ix		keep as Data.Ix
     5. Array		keep as Data.Array
     6. List		keep as Data.List
     7. Maybe		keep as Data.Maybe
     8. Char		keep as Data.Char
     9. Monad		keep as Control.Monad
    10. IO		keep as System.IO
    11. Directory	drop
    12. System		drop (superseded by System.Process)
    13. Time		drop
    14. Locale		drop
    15. CPUTime		drop
    16. Random		drop

The slightly odd thing here is keeping System.IO but dropping the other
IO libs Directory and System. We obviously have to drop System, because
it's more or less a deprecated API and it's superseded by System.Process
(which we almost certainly do not want to standardise at this stage).

It'd be nice to have a clear dividing line of keeping the pure stuff and
dropping the bits for interacting with the system however we have to
keep System.IO since bits of it are re-exported through the Prelude
(unless we also trim the Prelude). The bits for interacting with the
system are of course exactly the bits that are most prone to change and
are most in need of improvement.

Another quirk is that we never changed the name of the Numeric module.

Duncan