Haskell 2010: libraries

[Duncan Coutts]

On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote:
> 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.

Though also note that we have not changed any of the existing ones. Is
there a problem with specifying in the libraries section of the report
that the exports are a minimum and not a maximum?

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

Some functions, especially the pure ones are really part of the
character of the language (and some are specified as part of the
syntax). We have not had major problems with the pure parts of the
standard libraries, our problems have almost all been with the system
facing parts (handles, files, programs, exceptions).

I don't see any particular problem with having some essential (in the
sense of being part of the essence of the language) libraries in the
main report and some separate libraries report in a year or two's time
standardising some of the trickier aspects of libraries for portable
programs to interact with the OS (addressing Malcolm's point about the
need for this so as to be able to write portable programs).

Duncan