On Fri, Apr 30, 2010 at 09:37:39PM +0100, Simon Marlow wrote:
On 30/04/10 13:19, Malcolm Wallace wrote:
4. Provide a haskell2010 package and a base2010 package that re-exports all of base except the modules that overlap with haskell2010. You can either use haskell2010, haskell2010+base2010, or base. This is a bit like (1), but avoids the need for shadowing by using package re-exports, on the other hand confusion could well arise due to the strange base2010 package, and some people would surely try to use haskell2010 + base and run into difficulties.
In many ways this corresponds to my preferred solution, although I would rephrase it thus:
* Deprecate use of the "base" package, (I do not mean to remove "base", just to freeze it, and discourage its general use.) * Create a new "haskell2010" package (for ghc this will be built on topcommon of "base", but other compilers might make a different choice). * Create a new "portablebase" package which contains (or re-exports) all of the remaining useful and portable parts of the current "base" _and_ "haskell2010". * Create a new "ghcextras" package which re-exports (or defines afresh) all of the useful but non-portable parts of the current "base".
So it seems this is closer to option (2) in my message, because portablebase and haskell2010 overlap, and are therefore mutually exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping - that's the crucial difference.
If they are non-overlapping, how would a new Data.List function be added? Or an existing Data.List function be altered? No matter what solution is chosen, changes to datatypes or classes seem likely to be troublesome. I think the library change plans are underdeveloped, the libraries should be unchanged in H2010, and we should resolve this issue before changing them in a future language revision. That would keep other options open, such as the report standardising Haskell2011.Data.List rather than Data.List, etc.
I described this as a non-option because I thought trying to use the packages together might be a common problem that leads to obscure error messages about ambiguous modules, but perhaps it's not that bad, or at least not worse than the other solutions.
Direct imports of base* and haskell* could be (dis)allowed by the implementation depending on whether it is in "Haskell 2010 mode" or not.
We hope in the future that the set of libraries standardised in the report grows beyond what we have in base currently
Oh, I thought the plan was for library standardisation in the report to be reduced, with perhaps the Haskell Platform becoming the new library standardisation effort. Thanks Ian