[GHC] #10143: Separate PprFlags (used by Outputable) from DynFlags

[GHC]

#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