suggestions should go under the heading that best describes the reasons they should be included.

Require or could use compiler support

• Data.Typeable
• Data.Dynamic
• Control.Monad.Fix (for the IO instance)

useful in interfaces between unrelated modules

• Data.Map
• Data.Set
• Data.Monoid

generally useful/improvements

• ReadP and associated changes to the 'Read' class - the current Read specified by the report leaks memory like a fish and ReadP is signifigantly faster/better. We would also get a basic parsing library with the deal.

• There are even better ways to improve the Read class. The current signatures are just unhelpful - either you get a value or you don't, with no indication of what went wrong if it could not be parsed. A proper Read/Parse class should use an Either monad to allow error messages to be collected, and returned to the user. (I have a specific proposal in mind, currently in an experimental implementation in the HaXml? libraries. - Malcolm Wallace)

On the importance of standardizing libraries

• Is there a point to have a library codified in the standard when the fptools library is the de-facto standard anyway? Does it make a practical difference for anyone?

I think so. A library that's in the standard might have specifications of functions. Thus different implementations of the library can be compared w.r.t. a definitive specification. Another point is stability. For example, the step from GHC 6.2 to GHC 6.4 caused quite a few library interfaces to change incompatibly. As a result, programs didn't compile any longer. On the other hand, the Haskell-98-standard libs are still supported. I think we should strive for stability of library interfaces. Whether it has to be by including libraries into the standard or by other means, I don't know. -- Andres