[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