#10143: Separate PprFlags (used by Outputable) from DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10961 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dalaing): I've just been bringing everything used by the the pretty printer across from `DynFlags` into `PprFlags` up to this point. I agree that `PprFlags` isn't a great place for `PlatformConstants`, but at the moment the pretty printing code uses `PlatformConstants` (via the Outputable instances for Cmm, amongst others), so it seems like it is needed for this kind of direct translation (unless I'm misssing something here). At the moment the Cmm code in questions takes a `DynFlags` as an argument, solely to use the `PlatformConstants` contained within `DynFlags`. I've recently been playing with a `HasPlatformConstants` typeclass, with instances for `DynFlags` and `PprFlags`, since there are a few utility functions around the place that make of `PlatformConstants` via a `DynFlags` and may not be so easy to change. If `targetPlatform` joins that class it would open some other doors. Although that might be digging too far down the wrong rabbit hole. The separation of `PprFlags` from `DynFlags` also means that `sdocWithDynFlags` becomes `sdocWtihPprFlags`, and for some of the `Outputable` instances those flags are the only way they have access to certain kinds of information. That makes `PprFlags` into a bottleneck by which various Outputable instances gather information they need (including which of certain flags are on, which of certains extensions are enabled). It'd be nice to be able to address that. @ezyang mentioned in IRC that it might be easier to add another typeclass like `Outputable` but with access to `DynFlags`. I'll probably have a look at that next, but I'm worried that the work required to thread the `DynFlags` to where they are needed might be a neutral or net negative move. It would be nice to not have a random handful of flags and extensions in `PprFlags` though, so I'll definitely give it a go. In the short-term I'm focusing on getting everything but the Cmm code working, after which I'll give `OutputableWithDyn` a go. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10143#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler