#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