No, I do not really have a use case. I discovered it upon recompiling an older program whereupon the pretty printing behaviour changed which is how I discovered the inconsistency between the code and the documentation. Essentially, I just wanted to make columns, one line at a time. So, -- dwiw == do what i (basically) want dwiw :: [Doc] -> Doc dwiw = foldr ($$) empty f2 :: ([Doc] -> Doc) -> IO () f1 = \f -> (putStrLn $ render $ f [nest 0$text "abc", nest 10$text "def", nest 20$text "hig"]) f2 :: ([Doc] -> Doc) -> IO () f2 = \f -> (putStrLn $ render $ f [nest 0$text "abc", nest 10$text "def4567890123456789", nest 20$text "hig"]) *> mapM_ f1 [vcat,dwiw] abc def hig abc def hig *> mapM_ f1 [vcat,dwiw] abc def4567890123456789 hig abc def4567890123456789 hig Does that make visual sense? The logic is as follows: 1/ Figure out the size of your columns in advance to use nest; 2/ Require that the sum of the columns sizes is less than or equal to the maximum length of line that you are willing to tolerate; and 3/ dwiw splits the line if and when needed. Cheers, - Marcus P.S. I missed your previous post Ian; thanks for it. Benedikt Huber wrote:
Ian Lynagh schrieb:
On Wed, Feb 24, 2010 at 01:10:38PM +0100, Marcus D. Gabriel wrote:
The documentation for Text.PrettyPrint.HughesPJ states that vcat is the "List version of $$", but it works as the list version ($+$).
So either the documentation needs to be changed or the code. It would be nice to have both versions.
Hi, do you have a actual use case for the "List version of $$" ? It would make a good test I suppose.
It looks like the behaviour changed in
Tue Jun 24 12:37:15 BST 2008 benedikt.huber@gmail.com * fillNB bug, lazy vcat
i.e. the version that came with GHC 6.10. As it's had the current behaviour for some time, it would probably make sense to have a library submission to determine what the behaviour should be, and whether we want another function for the other behaviour: http://www.haskell.org/haskellwiki/Library_submissions
This is indeed a bug; I've reported it back in December 2008, but unfortunately did not file a bug report:
http://www.haskell.org/pipermail/libraries/2008-December/011032.html (at the end of the message, starting with [1])
Personally I think the "List version of $+$" is more common, but changing the implementation seems also fine.
It would be nice to solve the other (trickier) issue discussed in the mail referenced above as well.
cheers, benedikt