Re: GHC pretty printer philosophy

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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs