On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote:
> 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:
> 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.
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
The slightly odd thing here is keeping System.IO but dropping the other
IO libs Directory and System. We obviously have to drop System, because
it's more or less a deprecated API and it's superseded by System.Process
(which we almost certainly do not want to standardise at this stage).
It'd be nice to have a clear dividing line of keeping the pure stuff and
dropping the bits for interacting with the system however we have to
keep System.IO since bits of it are re-exported through the Prelude
(unless we also trim the Prelude). The bits for interacting with the
system are of course exactly the bits that are most prone to change and
are most in need of improvement.
Another quirk is that we never changed the name of the Numeric module.
Duncan
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
