[GHC] #10144: Variant of runGhc which accepts prelude for setting up DynFlags

[GHC]

#10144: Variant of runGhc which accepts prelude for setting up DynFlags
-------------------------------------+-------------------------------------
              Reporter:  ezyang      |             Owner:
                  Type:  bug         |            Status:  new
              Priority:  normal      |         Milestone:
             Component:  Compiler    |           Version:  7.11
              Keywords:              |  Operating System:  Unknown/Multiple
          Architecture:              |   Type of failure:  None/Unknown
  Unknown/Multiple                   |        Blocked By:
             Test Case:              |   Related Tickets:
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------
 One of the long-standing awkwardness of using the GHC API is the need to
 call `setSessionDynFlags` *again* after you finish setting up the DynFlags
 with all the parameters you care about. Furthermore, you must run
 `getSessionDynFlags` AGAIN in order to get the "most up-to-date" version
 of `DynFlags`, because the package initialization process twiddles with
 values in `DynFlags`.

 That's terrible.

 What we would like to do is set an invariant that there will be NO non-
 user changes to DynFlags. That means `pkgDatabase`, `pkgState` and
 `thisPackage`, which are twiddled by `initPackages`, really *ought not* to
 live in `DynFlags`. This would also fix a pile of nattering about with
 copying these values between the interactive DynFlags and normal DynFlags.

 However, there is a problem with trying to do this: most of the functions
 in `Packages` assume only a `DynFlags` is available. And you can basically
 assume that you'll have a `DynFlags` everywhere; not so much for `HscEnv`.
 So actually fixing this would require a lot of code heaving around that
 I'm not too interested in at the moment.

 There is, however, something we can do that will make people's life's
 better: a new version of `runGhc` which also accepts a function from
 `GhcMonad m => DynFlags -> m DynFlags` which is responsible for taking the
 `DynFlags` and configuring it to some suitable state. Whatever is
 returned, GHC can then make the final modifications (e.g. filling in those
 fields) and finally setting it as the DynFlags in the HscEnv, and ALSO
 updating the unsafe global DynFlags.

 This is not too hard to do.  But is it the right thing to do?  I'd like to
 know.

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