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. 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. I think we can leave the question of whether to abstract the existing base into separate "portablebase" and "ghcextras" packages as a separate issue - there are merits to doing something like this for sure, but I'd like to focus specifically on Haskell 2010, and I think portablebase/ghcextras are orthogonal.
Because I suggest that "portablebase" re-export the "haskell2010" API in its entirety, it would be impossible to use both packages explicitly at the same time from a single module - users would need to choose one or the other. Also, packages which currently depend on "base" should be encouraged to upgrade to a dependency on "haskell2010" rather than on "portablebase", if possible, because it provides greater stability of interface.
We hope in the future that the set of libraries standardised in the report grows beyond what we have in base currently, so I'm not sure how much sense it makes for portablebase to re-export the haskell20xx modules. Generally speaking we've been tyring to make base smaller rather than larger. Indeed right now there are some modules in the report that aren't in base, although those are the ones we're considering removing in this iteration. I like the picture where we have a small base, lots of independent packages, and one or more haskell20xx packages that re-exports all the standardised stuff from the other packages. This arrangement extends smoothly, the only problem is that haskell20xx overlaps with the other packages.
5. Not have a haskell2010 package, but have the report say that implementations are allowed to add things to the standard libraries.
This seems superficially attractive, but I think it would be impossible in practice to guarantee anything. For instance, the semantics of "take" and "drop" changed between Haskell 1.4 and Haskell'98 iirc, with no corresponding change in the API. With separate packages it is possible to retain and choose between both sets of semantics.
Yes, I agree - that's a non starter. Cheers, Simon