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