Haskell 2010: libraries

[Ian Lynagh]

On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote:
> 
> 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

We've been fortunate recently that, because the hierarchical modules
haven't been in the standard, we've been able to extend and improve them
without breaking compatibility with the language definition. In some
cases, such as the changes to how exceptions work, we haven't had this
freedom as the relevant functions are exposed by the Prelude, and that
has been causing us grief for years.

To take one example, since List was immortalised in the H98 report with
104 exports, Data.List has gained an additional 7 exports:
    foldl'
    foldl1'
    intercalate
    isInfixOf
    permutations
    stripPrefix
    subsequences
The last change (making the behaviour of the generic* functions
consistent with their non-generic counterparts) was less than a year
ago, and the last additions were less than 2.

It seems unlikely to me that all these libraries are finally perfect. If
we freeze them too solidly then I'm sure that we will regret it.

It is true that, with yearly language revisions, we have an annual
opportunity to fix any problems. However, we also want the
implementations to support several releases at once, and maintaining
those old base libraries would be a lot of work and confusion for the
minimal amount of benefit they would provide.

But to me, the most compelling argument for dropping them from the
report is that I can see no benefit to standardising them as part of the
language, rather than in a separate "base libraries" standard. We would
be able to act as if they were one standard if that were most
convenient, but we would have the flexibility to take advantage of them
being separate if necessary.


Thanks
Ian