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.
It seems unlikely to me that all these libraries are finally perfect. If
we freeze them too solidly then I'm sure that we will regret it.
It is true that, with yearly language revisions, we have an annual
opportunity to fix any problems. However, we also want the
implementations to support several releases at once, and maintaining
those old base libraries would be a lot of work and confusion for the
minimal amount of benefit they would provide.
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. We would
be able to act as if they were one standard if that were most
convenient, but we would have the flexibility to take advantage of them
being separate if necessary.
Thanks
Ian
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
