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

6 Mar 2015

      #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:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------
Description changed by ezyang:

Old description:
...
At the moment, SDoc computations have full access to the entirety of
DynFlags, despite only a minusculely small amount of the data structure
being relevant to them.  This proposal is to split out a `PprFlags`
structure which will be contained in a `DynFlags`, and contain dynamic
flags JUST for pretty-printing. There will be a function `pprFlags ::
DynFlags -> PprFlags`. This also helps eliminate the circular dependency
between `DynFlags` and `Outputable`.
This structure is not complete, but it should give a sense for some of
the things
that need to be put in here:
{{{
data PprFlags = PprFlags {
  pprUserLength         :: Int,
  pprCols               :: Int,
useUnicode      :: Bool,
  useUnicodeSyntax :: Bool,
  targetPlatform :: Platform,
suppressUniques :: Bool,
  errorSpans :: Bool,
  suppressModulePrefixes :: Bool
    }
}}}
I have a patch in-progress which factors this out, but I want to get some
sign-offs that this is a good refactoring before I finish it.
Thanks!
New description:

 At the moment, SDoc computations have full access to the entirety of
 DynFlags, despite only a minusculely small amount of the data structure
 being relevant to them.  This proposal is to split out a `PprFlags`
 structure which will be contained in a `DynFlags`, and contain dynamic
 flags JUST for pretty-printing. There will be a function `pprFlags ::
 DynFlags -> PprFlags`. This also helps eliminate the circular dependency
 between `DynFlags` and `Outputable`.

 This structure is not complete, but it should give a sense for some of the
 things
 that need to be put in here:

 {{{

 data PprFlags = PprFlags {
   pprUserLength         :: Int,
   pprCols               :: Int,

   useUnicode      :: Bool,
   useUnicodeSyntax :: Bool,
   targetPlatform :: Platform,

   suppressUniques :: Bool,
   errorSpans :: Bool,
   suppressModulePrefixes :: Bool,
   printExplicitKinds :: Bool,
   printExplicitForalls :: Bool,
   suppressTypeSignatures :: Bool,
   suppressIdInfo :: Bool,
   suppressCoercions :: Bool,
   pprCaseAsLet :: Bool,
   pprShowTicks :: Bool,
   suppressTypeApplications :: Bool,
   sccProfilingOn :: Bool,

     }
 }}}

 I have a patch in-progress which factors this out, but I want to get some
 sign-offs that this is a good refactoring before I finish it.

 The most annoying bits are pretty-printing in the code generator, where
 all of the platform constants (e.g. word-size) are necessary to print the
 right way.

--

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10143#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler