Opened 19 months ago

Last modified 10 months ago

#10827 new feature request

GHCi should support interpeting multiple packages/units with separate DynFlags

Reported by: ezyang Owned by:
Priority: normal Milestone:
Component: GHC API Version: 7.11
Keywords: backpack Cc: alanz, DanielG
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


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:

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).
  1. 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.

Change History (3)

comment:1 Changed 17 months ago by mgsloan

A couple other things that would be needed for proper multi-package ghci:

  1. Per-package working directory, so that we can load files with relative paths, via TH. I'm imagining that this would work by changing the CWD before compiling a file or before running each splice. If we're allowing this bit of environment to vary, it also would be consistent to support different environment variables. I've never seen TH depend on that, though, so not very important..
  1. Per-package restriction of dependencies (-hide-all-packages / -package). Otherwise, it couldn't deal with the case where two of your packages depend on the same module name, imported from different packages.
  1. Support for package qualified imports amongst your local packages.

comment:2 Changed 17 months ago by alanz

Cc: alanz added

comment:3 Changed 10 months ago by DanielG

Cc: DanielG added
Note: See TracTickets for help on using tickets.