#9375: Support for module thinning/renaming on command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In #8407, we added the capability for packages to reexport modules from other packages. This ticket is for the dual operation: during the compilation of a module, rather than being forced dump all of the exposed modules of package foo when I say `-package foo`, I should be able to selectively pick which modules I make visible (thinning) and rename them, if I like. For now, the proposed syntax is for all package flags, I can now write `-package "foo (A as B, C)"`. This feature has special implications for how the package database hiding/showing works. Currently, if I write `-package foo-0.1`, this will automatically go ahead and un-expose any other packages named `foo` that I may have loaded. But if I write `-package foo-0.1 (Foo as Foo1) -package foo-0.2 (Foo as Foo2)`, I probably didn't actually want to hide the old instance of `foo-0.1` when I exposed `foo-0.2`. More generally, rather than thinking of package configuration as flipping exposed/not-exposed bits on and off of an in-memory package database, we would rather think of it as setting up a mapping of module names to their implementations, and only reporting a conflict when there is an inconsistent module mapping. Since this is a change of behavior, I propose two sets of semantics, controlled by a flag `-backpack` (but really, I mostly care about the second set). Flag naming can be negotiated. In the **absence** of `-backpack`, thinning/renaming works by modifying the exposed/reexported module fields of the matched packages in the database. However, the old hiding behavior still applies, so this functionality would primarily be useful if two separate packages exported a module with the same name, and you still wanted to use both of them. So, the original example would not do what you want, but `-package mtl (Control.Monad.Trans as MtlTrans) -package transformers (Control.Monad.Trans as TransformersTrans)` would DTRT. **With** the `-backpack` flag, no auto-hiding of packages occurs (this affects flags with thinning and renaming). Furthermore, the package database is cleared, as would be done with `-hide-all-packages`. We replace the old resolution algorithm with the new one, which processes each flag one-by-one while building a module mapping, picking a package which is consistent with the currently selected set of packages. This consistency is done by looking at the current module mapping and ensuring all of the modules the package would bring into scope are consistent with the modules we have already. Both example shown before would work; furthermore, `-package foo -package foo` would also continue to work, since `foo`'s exports are consistent with itself. However, `-package foo-0.1 -package foo-0.2` would be rejected (whereas now it is accepted.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9375 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler