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