Thomas Schilling wrote:
On Sun, 2007-10-28 at 13:49 -0400, Isaac Dupree wrote:
Simon Marlow wrote:
Probably it could be made clearer. In 4.2 the idea is that instead of replacing
base-2.0 ==> base-3.0 + directory-1.0 + array-1.0 + ...
you would replace
base-2.0 ==> newbase-1.0 + directory-1.0 + array-1.0 + ...
and additionally have a package base-3.0 that re-exports the whole of (newbase + directory + array + ...). "Macros" in cabal: Why not just say that depending on base-3.0 actually means that you have to depend on newbase-1.0, and directory-1.0, etc... Why is compiler support needed? is it really possible that I still don't understand?
You'd still have the problem that every package has to specify this "macro" for itself. You'd want some global macro-database to avoid this. The better solution would be to just have a package that re-exports everything. I.e., the definition of package base-2.0 would look something like this:
if has system has base-3.0, directory, array ... re-export else exposed-modules: Data.Maybe, Data.List, ...
And this runs into trouble when base-3.0 has changes to datatypes and/or classes relative to base-2.0 (see 4.1 of http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility). This approach doesn't scale; it may be useful for providing backwards-compatible versions of smaller packages, but impractical for base. Cheers, Simon