Text.PrettyPrint bug or doc bug

[Marcus D. Gabriel]

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 at 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