[GHC] #10603: Output of -ddump-splices is parenthesized incorrectly
GHC
ghc-devs at haskell.org
Mon Dec 14 15:27:55 UTC 2015
#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
More information about the ghc-tickets
mailing list