Restructure code base.
[packages/pretty.git] / CHANGELOG
1 ======== CHANGE LOG ==========
2
3 Pretty library change log.
4
5 ========= Version 4.0, 24 August 2011 ==========
6
7 * Big change to the structure of the library. Now we don't have a fixed
8   TextDetails data type for storing the various String types that we
9   support. Instead we have changed that to be a type class that just
10   provides a way to convert String and Chars to an arbitary type. This
11   arbitary type is now provided by the user of the library so that they
12   can implement support very easily for any String type they want.
13
14   This new code lives in Text.PrettyPrint.Core and the Text.PrettyPrint
15   module uses it to implement the old API. The Text.PrettyPrint.HughesPJ
16   module has been left unchanged for a compatability module but deprecated.
17
18 ========= Version 3.0, 28 May 1987 ==========
19
20 * Cured massive performance bug. If you write:
21
22     foldl <> empty (map (text.show) [1..10000])
23
24   You get quadratic behaviour with V2.0. Why? For just the same
25   reason as you get quadratic behaviour with left-associated (++)
26   chains.
27
28   This is really bad news. One thing a pretty-printer abstraction
29   should certainly guarantee is insensitivity to associativity. It
30   matters: suddenly GHC's compilation times went up by a factor of
31   100 when I switched to the new pretty printer.
32   
33   I fixed it with a bit of a hack (because I wanted to get GHC back
34   on the road). I added two new constructors to the Doc type, Above
35   and Beside:
36   
37     <> = Beside
38     $$ = Above
39   
40   Then, where I need to get to a "TextBeside" or "NilAbove" form I
41   "force" the Doc to squeeze out these suspended calls to Beside and
42   Above; but in so doing I re-associate. It's quite simple, but I'm
43   not satisfied that I've done the best possible job. I'll send you
44   the code if you are interested.
45
46 * Added new exports:
47     punctuate, hang
48     int, integer, float, double, rational,
49     lparen, rparen, lbrack, rbrack, lbrace, rbrace,
50
51 * fullRender's type signature has changed. Rather than producing a
52   string it now takes an extra couple of arguments that tells it how
53   to glue fragments of output together:
54
55     fullRender :: Mode
56                -> Int                       -- Line length
57                -> Float                     -- Ribbons per line
58                -> (TextDetails -> a -> a)   -- What to do with text
59                -> a                         -- What to do at the end
60                -> Doc
61                -> a                         -- Result
62
63   The "fragments" are encapsulated in the TextDetails data type:
64
65     data TextDetails = Chr  Char
66                      | Str  String
67                      | PStr FAST_STRING
68
69   The Chr and Str constructors are obvious enough. The PStr
70   constructor has a packed string (FAST_STRING) inside it. It's
71   generated by using the new "ptext" export.
72
73   An advantage of this new setup is that you can get the renderer to
74   do output directly (by passing in a function of type (TextDetails
75   -> IO () -> IO ()), rather than producing a string that you then
76   print.
77
78
79
80 ========= Version 3.0, 28 May 1987 ==========
81
82 * Made empty into a left unit for <> as well as a right unit;
83   it is also now true that
84     nest k empty = empty
85   which wasn't true before.
86
87 * Fixed an obscure bug in sep that occasionally gave very weird behaviour
88
89 * Added $+$
90
91 * Corrected and tidied up the laws and invariants
92
93
94
95 ========= Version 1.0 ==========
96
97 Relative to John's original paper, there are the following new features:
98
99 1. There's an empty document, "empty". It's a left and right unit for
100    both <> and $$, and anywhere in the argument list for
101    sep, hcat, hsep, vcat, fcat etc.
102
103    It is Really Useful in practice.
104
105 2. There is a paragraph-fill combinator, fsep, that's much like sep,
106    only it keeps fitting things on one line until it can't fit any more.
107
108 3. Some random useful extra combinators are provided.
109      <+> puts its arguments beside each other with a space between them,
110          unless either argument is empty in which case it returns the other
111
112
113      hcat is a list version of <>
114      hsep is a list version of <+>
115      vcat is a list version of $$
116
117      sep (separate) is either like hsep or like vcat, depending on what fits
118
119      cat  behaves like sep,  but it uses <> for horizontal composition
120      fcat behaves like fsep, but it uses <> for horizontal composition
121
122      These new ones do the obvious things:
123        char, semi, comma, colon, space,
124        parens, brackets, braces,
125        quotes, doubleQuotes
126
127 4. The "above" combinator, $$, now overlaps its two arguments if the
128    last line of the top argument stops before the first line of the
129    second begins.
130
131      For example:  text "hi" $$ nest 5 (text "there")
132      lays out as
133                    hi   there
134      rather than
135                    hi
136                         there
137
138    There are two places this is really useful
139
140      a) When making labelled blocks, like this:
141             Left ->   code for left
142             Right ->  code for right
143             LongLongLongLabel ->
144                       code for longlonglonglabel
145         The block is on the same line as the label if the label is
146         short, but on the next line otherwise.
147
148      b) When laying out lists like this:
149             [ first
150             , second
151             , third
152             ]
153         which some people like. But if the list fits on one line you
154         want [first, second, third]. You can't do this with John's
155         original combinators, but it's quite easy with the new $$.
156
157    The combinator $+$ gives the original "never-overlap" behaviour.
158
159 5. Several different renderers are provided:
160      * a standard one
161      * one that uses cut-marks to avoid deeply-nested documents
162        simply piling up in the right-hand margin
163      * one that ignores indentation (fewer chars output; good for machines)
164      * one that ignores indentation and newlines (ditto, only more so)
165
166 6. Numerous implementation tidy-ups
167    Use of unboxed data types to speed up the implementation
168
169