Bugs item #940294, was opened at 2004-04-22 13:16
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=940294&group_id=8032

Category: libraries (other)
Group: 6.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Cast (jcast)
Assigned to: Nobody/Anonymous (nobody)
Summary: Language.Haskell.Pretty misformats 

Initial Comment:
ghci gives the following results:

$ ghci -fglasgow-exts
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version
6.2.1, for Haskell 98.
/ /_\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.
 
Loading package base ... linking ... done.
Prelude> :m + Language.Haskell.Syntax
Prelude Language.Haskell.Syntax> :m +
Language.Haskell.Pretty Prelude Language.Haskell.Syntax
Language.Haskell.Pretty> putStrLn $ prettyPrint  $
HsInfixApp (HsDo [HsQualifier (HsVar (UnQual (HsIdent
"undefined"))), HsQualifier (HsVar (UnQual (HsIdent
"undefined")))]) (HsQVarOp (UnQual (HsSymbol "<|>")))
(HsDo [HsQualifier (HsVar (UnQual (HsIdent "undefined")))])
Loading package haskell98 ... linking ... done.
Loading package haskell-src ... linking ... done.
do undefined
   undefined
  <|> do undefined
Prelude Language.Haskell.Pretty
Language.Haskell.Syntax> putStrLn $ prettyPrint $ HsApp
(HsVar (UnQual (HsIdent "foo"))) $ HsApp (HsVar (UnQual
(HsIdent "bar"))) $ HsVar (UnQual (HsIdent "baz"))
foo bar baz

In other words, it mis-indents infix applications and
does /not/ parenthesize nested applications.  There may
be other mis-formatting issues, but these are the ones
that have me stopped atm.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-04-23 16:55

Message:
Logged In: NO 

I'm not clear on what behaviour you want for the original
example. It must indent the <|>, because the do might itself
be a statement of another do expression. In the bigger one,
you've explicitly asked for an onsideIndent that's the same
as the doIndent, when it should always be smaller. I'll add
this and similar preconditions to the documentation.

The documentation is also lacking in relation to HsParen.
I'm reluctant to improve pretty by adding parentheses,
partly because it's work, and partly because it's only a
partial solution and it's not clear how infix operators
should be handled.

-- Ross

----------------------------------------------------------------------

Comment By: Jon Cast (jcast)
Date: 2004-04-23 15:14

Message:
Logged In: YES 
user_id=762054

Patterson: Well, the first one is more of a QOI issue (and
possibly debatable, although I can't imagine who'd want that
behavior).  As for the second issue: are you saying that
(HsApp <foo> (HsApp <bar> <baz>)) is simply illegal or in
some way wrong?  That doesn't seem to be documented, and
seems like a bad idea to me anyway.  IMHO, it's the most
natural use from the POV of someone reading the Haddock
documentation HsParen is very hard to find, and it's not at
all obvious that it is /required/ whenever the Haskell
syntax requires parentheses.

But, I was inspired to report the first issue by the
following (more complex) test case, which I'm going to
report in full here as it's not too long and definitely
shows incorrect behavior:

putStrLn $ prettyPrintStyleMode style (PPHsMode 2 2 2 2 2 2
True PPOffsideRule False False) $ (HsInfixApp (HsDo
[HsQualifier (HsApp (HsVar (UnQual (HsIdent "reserved")))
(HsLit (HsString "LineTo"))), HsGenerator (SrcLoc
{srcFilename = "stdin", srcLine = 1, srcColumn = 1}) (HsPVar
(HsIdent "curveSegmentEndPoint")) (HsVar (UnQual
(HsIdent"parse"))), HsQualifier (HsApp (HsVar (UnQual
(HsIdent "return"))) (HsApp (HsCon (UnQual (HsIdent
"CurveLineTo"))) (HsVar (UnQual (HsIdent
"curveSegmentEndPoint")))))]) (HsQVarOp (UnQual (HsSymbol
"<|>"))) (HsDo [HsQualifier (HsApp (HsVar (UnQual (HsIdent
"reserved"))) (HsLit (HsString "LineAlong"))),HsGenerator
(SrcLoc {srcFilename = "stdin", srcLine = 1, srcColumn = 1})
(HsPVar (HsIdent "curveSegmentAlong")) (HsVar (UnQual
(HsIdent "parse"))),HsQualifier (HsApp (HsVar (UnQual
(HsIdent "return"))) (HsApp (HsCon (UnQual (HsIdent
"CurveAlong"))) (HsVar (UnQual (HsIdent
"curveSegmentAlong")))))]))
do
  reserved "LineTo"
  curveSegmentEndPoint <- parse
  return CurveLineTo curveSegmentEndPoint
  <|>
  do
    reserved "LineAlong"
    curveSegmentAlong <- parse
    return CurveAlong curveSegmentAlong

Note that the operator here is indented by /two/ spaces,
same as the statements in the first do expression.

This behavior can, oddly enough, be fixed by using
defaultMode instead of an explicit PPHsMode constructor, but
I can't find any other work-around.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-04-22 16:10

Message:
Logged In: NO 

I don't see the problem with the first one: <|> must be
indented less
than the do body to force a }, but not so much that it
forces a ; in an
outer layout context.

Regarding the second one, prettyPrint never inserts
parentheses in
expressions. You have to use HsParen, and the parser leaves
those
in the parse tree. If you're generating source, you'll need
to add it.
Maybe it should be smarter than that, but it would still be
limited,
since there's no information about operator fixity.

-- Ross Paterson

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=940294&group_id=8032
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to