#10603: Output of -ddump-splices is parenthesized incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dnusbaum Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10703 | Differential Rev(s): Phab:D1114 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 8.2.1 => 8.0.1 Comment: This whole ticket is just symptomatic of a broader issue. As Richard says: "The problem is that HsExpr is intended to be parsed Haskell source. Printing should thus be a breeze: the programmer had to insert all the necessary parens, so we just spit back out what the programmer said. "However, splicing in TH also produces HsExpr. Because it's not programmer-specified, the parentheses are unnecessary here, because no parser will ever look at it. But here we do want parentheses. "We could try to get the HsExpr pretty-printer to be smarter about all of this. But I think that's barking up the wrong tree -- ideally, the HsExprpretty-printer should be very dumb about parentheses. (Indeed, I believe that ppr_expr should never recur into pprParendExpr. But that's more than we need to accomplish today.) "Instead, I think a better approach is to have the Convert module add HsPar nodes. By doing this, we make it more possible that printing HsExpr will be exactly what the programmer wrote, while still getting valid output from TH." And in `HsExpr` we find {{{ HsSyn records exactly where the user put parens, with HsPar. So generally speaking we print without adding any parens. However, some code is internally generated, and in some places parens are absolutely required; so for these places we use pprParendExpr (but don't print double parens of course). For operator applications we don't add parens, because the operator fixities should do the job, except in debug mode (-dppr-debug) so we can see the structure of the parse tree. }}} I like Richard's proposed solution. Let's do that rather than making an ad-hoc fix for this particular example. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10603#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler