[GHC] #1337: Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and fsep)

[GHC]

#1337: Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and fsep)
-------------------------------+--------------------------------------------
    Reporter:  thorkilnaur     |        Owner:  thorkilnaur
        Type:  bug             |       Status:  new        
    Priority:  normal          |    Milestone:             
   Component:  libraries/base  |      Version:  6.6.1      
    Severity:  normal          |   Resolution:             
    Keywords:                  |   Difficulty:  Unknown    
          Os:  Unknown         |     Testcase:  pp2        
Architecture:  Unknown         |  
-------------------------------+--------------------------------------------
Changes (by thorkilnaur):

  * owner:  => thorkilnaur

Comment:

 Thank you, I'll try to do that. In view of the level of correctness of the
 comment that you quote (note the missing occurrence of {{{p2}}} in the
 second operand of the {{{`union`}}}), I should have a fair chance of at
 least not making things worse (ho ho).

 Unless otherwise directed, I will assume that it is OK to add test cases
 to {{{testsuite/tests/ghc-regress/lib/PrettyPrint}}} following the lead
 from trac #1062.

 I would like to mention a consequence of correcting {{{fill}}} as
 suggested which may cause surprise and which I therefore better discuss
 early. As described, I understand the basic idea of {{{fill}}} to be such
 that
 {{{
 fill g [x0, x1, ..., xn] = ( ... (x0 `p1` x1) `p2` ... ) `pn` xn
 }}}
 where each {{{pi}}} is either one of {{{<>}}} and {{{<+>}}} (depending on
 g) or {{{$$}}} so that the lines fill nicely. Thus, the example that I
 gave:
 {{{
 nest 3 $ fcat [nest 1 (text "a"), nest 2 (text "b"), text "c"]
 }}}
 evaluates to:
 {{{
 nest 3 $ (nest 1 (text "a") <> nest 2 (text "b")) $$ text "c"
 }}}
 leading to the {{{c}}} indented one position to the left of the {{{a}}}.
 Consider now:
 {{{
 nest 3 $ text "|" <> (fcat [nest 1 (text "a"), nest 2 (text "b"), text
 "c"])
 }}}
 where a {{{|}}} has been concatenated in front of the {{{fcat}}}. This, of
 course, causes the nest 1 of the {{{a}}} to be eliminated, but the
 relative position of the {{{ab}}} and the {{{c}}} on the next line is
 retained, leading to this output:
 {{{
 ...|ab
 ...c
 }}}
 What may be surprising is that the {{{c}}}, part of the {{{fcat}}} list,
 doesn't stay to the right of the {{{|}}}. To avoid such surprises, nesting
 of things that get placed in {{{fill}}}s should perhaps be avoided.

 And nesting of things that are later {{{fill}}}ed is what causes the
 problematic behaviour reported in trac #1176: In
 {{{compiler/hsSyn/HsExpr.lhs}}}, we find:
 {{{
     pp_infixly v
       = sep [nest 2 pp_e1, pprInfix v, nest 2 pp_e2]
 }}}
 for pretty-printing an expression with infix operator. When this is
 combined with the {{{compiler/utils/Outputable.lhs}}} code for pretty-
 printing lists of Outputable things (here is the {{{fsep}}} that calls the
 {{{fill}}}):
 {{{
 instance (Outputable a) => Outputable [a] where
     ppr xs = brackets (fsep (punctuate comma (map ppr xs)))
 }}}
 called from {{{compiler/typecheck/TcExpr.lhs}}} that says:
 {{{
 funAppCtxt fun arg arg_no
   = hang (hsep [ ptext SLIT("In the"), speakNth arg_no, ptext
 SLIT("argument of"),
                     quotes (ppr fun) <> text ", namely"])
          4 (quotes (ppr arg))
 }}}
 we get the {{{fill}}}ing of {{{nest}}}ed things.

 The suggested correction of {{{fill}}} will prevent the incorrect
 wandering off of the left margin to minus infinity. But it will not
 prevent the (perhaps surprising) layout of {{{fill}}}ed things that start
 with something {{{nest}}}ed. In the case of
 {{{compiler/hsSyn/HsExpr.lhs}}}, the potential surprise may be prevented
 by writing:
 {{{
     pp_infixly v
       = sep [pp_e1, nest (-2) $ pprInfix v, pp_e2]
 }}}
 instead of the code actually used, but that, of course, affects the result
 of using this code in circumstances that are nested to a level less than
 2.

 Best regards
 Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1337>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
-------------- next part --------------
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs