[GHC] #10827: GHCi should support interpeting multiple packages/units with separate DynFlags

[GHC]

#10827: GHCi should support interpeting multiple packages/units with separate
DynFlags
-------------------------------------+-------------------------------------
              Reporter:  ezyang      |             Owner:
                  Type:  feature     |            Status:  new
  request                            |
              Priority:  normal      |         Milestone:
             Component:  GHC API     |           Version:  7.11
              Keywords:  backpack    |  Operating System:  Unknown/Multiple
          Architecture:              |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
             Test Case:              |        Blocked By:
              Blocking:              |   Related Tickets:
Differential Revisions:              |
-------------------------------------+-------------------------------------
 Stack and other tools are attempting to make the user-experience of
 developing multiple packages simultaneously better. Thus, if you have
 source packages p, q and r (which all depend on them), `stack build`
 builds all of them. They are quite interested in support `stack ghci` but
 there are problems: https://github.com/commercialhaskell/stack/issues/665

 The essence of the problem is twofold:

 1. If you ask GHCi to interpret modules from multiple packages (e.g. by
 having multiple source directories), GHCi currently only knows how to put
 all of them into the same home package. This will fail if two packages
 have a module with the same name; also, modules in the other packages will
 always see modules (even if they're supposed to be hidden).

 2. A GHCi session only has one global set of dynamic flags, but each
 package may be compiled with its own set of DynFlags (e.g. package global
 LANGUAGE pragmas). This means the "default DynFlags" needs to be varied
 between packages.

 It's not too obvious to me how to fix (1) (at least, you'd have to make
 the HPT support sets of HomeModInfos from multiple packages), but (2)
 seems tractable: since we already track DynFlags on a per-module basis, we
 just have to arrange for a "package" level DynFlag to be applied to the
 correct ModSummarys.

 Similar functionality would be useful for Backpack.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10827>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler