#669: negative indentation in Text.PrettyPrint.HughesPJ
------------------------------------------+---------------------------------
Reporter: [EMAIL PROTECTED] | Owner: thorkilnaur
Type: bug | Status: new
Priority: normal | Milestone: 6.8
Component: hslibs/text | Version: 6.4.1
Severity: minor | Resolution:
Keywords: | Difficulty: Unknown
Testcase: pp1 | Architecture: Unknown
Os: Unknown |
------------------------------------------+---------------------------------
Comment (by thorkilnaur):
In this investigation, I had earlier asked John Hughes about his comments
to the situation, since the problem was related to his original library.
With his permission, I quote his response:
{{{
Actually, the point you bring up was the intended behaviour of the
library... at least, intended by me! One of the properties I wanted the
library to enjoy was that wherever a document fragment was placed, the
layout of the fragment would be the same. Now, in its vertical form,
sep [nest 4 (text "a"), text "b"]
places the a 4 spaces to the right of the b:
a
b
The *relative* placement of the a and the b should remain the same,
whether or not this document is placed to the right of another. Thus,
for example,
text "foobar: " <> sep [nest 4 (text "a"), text "b"]
SHOULD be laid out as
foobar: a
b
to preserve the relationship between a and b. Of course, it follows that
indentations can be negative if the "foobar:" label is replaced by a
shorter one. This, I see as an error in the use of the library. Of
course, an intermediate document may well contain negative
indentation--it can still be pretty-printed correctly by applying nest k
to it at the top level, for a suitable k.
Of course, one might discuss whether this design it the right one. An
important principle for me was to start from a simple formal
specification--the set-based model in my paper--and then follow what it
told me. So if one were to explore alternative designs, one should start
not from the code, but from the formal model, and see whether a design
with a similarly simple formal model can be found.
John
}}}
So I will have to say that my repair and patch is certainly not in
accordance with the intentions of John Hughes.
I do not believe that I can contribute much further to this matter without
input as to the direction it should take, so I will put it down for now.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/669>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
