I'm afraid I've lost track of where this discussion took place (does someone else remember seeing it?), but I've advocated for faithful reproduction in the past. In particular, the pretty-printers for HsSyn should, in my opinion, never add or remove parentheses.
There is a problem here, though: sometimes HsSyn is produced within GHC (for example, in the implementation of `deriving`, or in splicing TH, among a few other spots). This HsSyn can get away with missing parentheses, because it's built as an unambiguous AST. But if the pretty-printer is always faithful, then pretty-printing such an AST will produce an unparsable string. Perhaps the answer is that the generated code should be generous with parentheses -- essentially moving the paren-adding code from today's pretty-printer to the generation sites. Bottom line here: I fully support this direction of travel, but it's not without bumps in the road. Richard > On Nov 12, 2016, at 5:12 AM, Alan & Kim Zimmerman <[email protected]> wrote: > > I am currently working on #3384, with the intent of ensuring that > > parse (ppr (parse source)) == parse source > > I have hit the issue where > > foo :: (Int) > > has the parens reflected in the original parsed AST, but the types pretty > printer goes to a lot of trouble to remove any parens not required to > interpret the meaning of the type. > > So the question is, should the default ppr faithfully reproduce the source > that was parsed to generate the given AST, or simplify it? > > From a round-tripping perspective I prefer the former, but there are other > use cases where the current behaviour is preferred. > > If the original is preferred, it can perhaps be enabled via a flag to the > pretty printer, but before doing that I want to see if it actually matters. > > Alan > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
