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