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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
