GHC pretty printer philosophy

[Richard Eisenberg]

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 <alan.zimm at gmail.com> 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
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs