Changelog for pretty-

Pretty library change log

Version 4.0, 24 August 2011

Version 3.0, 28 May 1987

Version 3.0, 28 May 1987

Version 1.0

Relative to John's original paper, there are the following new features:

  1. There's an empty document, "empty". It's a left and right unit for both <> and $$, and anywhere in the argument list for sep, hcat, hsep, vcat, fcat etc.

    It is Really Useful in practice.

  2. There is a paragraph-fill combinator, fsep, that's much like sep, only it keeps fitting things on one line until it can't fit any more.

  3. Some random useful extra combinators are provided. <+> puts its arguments beside each other with a space between them, unless either argument is empty in which case it returns the other

 hcat is a list version of <>
 hsep is a list version of <+>
 vcat is a list version of $$

 sep (separate) is either like hsep or like vcat, depending on what fits

 cat  behaves like sep,  but it uses <> for horizontal composition
 fcat behaves like fsep, but it uses <> for horizontal composition

 These new ones do the obvious things:
   char, semi, comma, colon, space,
   parens, brackets, braces,
   quotes, doubleQuotes
  1. The "above" combinator, $$, now overlaps its two arguments if the last line of the top argument stops before the first line of the second begins.

    For example: text "hi" $$ nest 5 (text "there") lays out as hi there rather than hi there

    There are two places this is really useful

    a) When making labelled blocks, like this: Left -> code for left Right -> code for right LongLongLongLabel -> code for longlonglonglabel The block is on the same line as the label if the label is short, but on the next line otherwise.

    b) When laying out lists like this: [ first , second , third ] which some people like. But if the list fits on one line you want [first, second, third]. You can't do this with John's original combinators, but it's quite easy with the new $$.

    The combinator $+$ gives the original "never-overlap" behaviour.

  2. Several different renderers are provided:

    • a standard one
    • one that uses cut-marks to avoid deeply-nested documents simply piling up in the right-hand margin
    • one that ignores indentation (fewer chars output; good for machines)
    • one that ignores indentation and newlines (ditto, only more so)
  3. Numerous implementation tidy-ups Use of unboxed data types to speed up the implementation