Malcolm Wallace schrieb:
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 top 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 "haskell2010" would be stable and unchanging. "portablebase" would be a superset of "haskell2010", and continue to evolve with community input, and parts of it would eventually migrate into "haskell2011", "haskell2012", etc. Meanwhile "ghcextras" would clearly delineate those language/library features that are not portable, and it could continue to grow, or indeed shrink, with some parts migrating into "portablebase" as the language definition adopts extensions, or as other compilers adopt implementation strategies.
To illustrate the forward compatibility story, I envisage that when "haskell2011" is created, a new version of "portablebase" would depend on (and re-export) it instead of "haskell2010". This would be OK because the "portablebase" API would be non-decreasing, and new Reports should not make library changes that have not already been trialled in the community. On the other hand, the "ghcextras" package would be free to shrink as functionality is gradually transferred to "portablebase".
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.
The overall dependency graph would look something like this:
/--- stablestuff /-- less-stable-stuff / / base --- haskell2010 --- portablebase ---\ \-- ghcextras ---------------------\=== experimental-stuff
Why do you want portablebase to be a superset of haskell2010 by re-export? Is it not better to have a package "baseextras" that depends on haskell2010 but only exports additional modules. Other packages can decide to depend on "haskell2010" only or on "haskell2010" and "baseextras" (instead of "portablebase" alone). Or do you want modules from "haskell2010" also to be "portablebase" but with additional functions (rather than putting new functions into new modules)? Cheers Christian