#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Here is an annoying problem for implementing this functionality. Module reexports should roughly be analogous to how we deal with type/declaration reexports at the Haskell source level. To briefly overview how that mechanism works, we have a phase of compilation called "renaming", which takes all identifiers and figures out what true names they refer to. This is done by consulting the hi files associated with imported modules, which record the original name of any identifiers they export. By analogy, the installed package information file is like an "hi" file, and we would like it to store a pointer to the original name of the module (in this case, the InstalledPackageId and original module name, if renaming is allowed.) However, there is trouble in paradise. Entries in the InstalledPackageDb are created by the Cabal library; however, the Cabal library has no knowledge about module resolution (it only looks at the dependencies to do dependency resolution): all of this logic is in GHC proper (Packages and Finder). So at the time Cabal is writing the installed package info, it would need to consult GHC in order to figure out where modules actually came from! This seems like a design smell. The alternative is to do module resolution in GHC. Here, we augment the creation of our module map (when processing `-package` flags) so that when we see a reexport, we consult the existing map and insert a pointer to precisely the original import. If the packages are passed to us in topologically sorted order (which Cabal seems to do today), then we only pay the cost of a single map lookup for every reexported module we encounter. The downside is that this mechanism is now no longer symmetric with original names. It's not really clear which one is better. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler