* Joachim Breitner
Hi,
not sure if this is the right mailing list, as it affects GHC and Cabal, but can be used by all library authors. But it is a close fit.
I’d like to propose Module re-reports on the package level, in order to make package reorganization easier on the users. For details, please see http://ghc.haskell.org/trac/ghc/wiki/ModuleReexports and for discussion, I suggest to use the trac ticket http://ghc.haskell.org/trac/ghc/ticket/8407
Questions are: * Is this useful enough? * Is the design (syntax and semantics) good?
This looks useful — it could help solve the problem of fine-grained packages, by providing a means to create meta-packages on which one can depend. For that it would be also useful to be able to re-export whole packages, similarly to how we can re-export modules from other modules. I have two concerns about versioning: 1. Suppose that package-a re-exports Data.Bar from package-b starting from package-a-2.0 and package-b-2.0. This means that we shouldn't prevent packages to be built with package-a-1.0 and package-b-2.0, because that would result in a duplicate module Data.Bar. Note that we cannot simply make package-b-2.0 depend on package-a >=2.0, because that would result in a recursive dependency. Yet it might be useful to tell the dependency solver that these packages are incompatible. 2. If package-b has a major API change, it would bump its version, say, to 3.0. package-a still has version 2.0, but now it re-exports a completely different API. Roman