Re: GHC pretty printer philosophy

[Alan & Kim Zimmerman]

Richard

Thanks for the support.  The major change in HsSyn since the pretty printer
was first written is that the parser now preserves parens in the original
source, which it did not used to, so this approach is now feasible.

And I am starting to bump into tests failing which require updating the
generic deriving code to add parens.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 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  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

GHC pretty printer philosophy

[Alan & Kim Zimmerman]

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