@@ -79,41 +79,9 @@ attempt to build a document representation to render
7979afterwards, instead it just prints the parsed code straight away. This means
8080that the 70-80% of what the code does is a printing traversal.
8181
82−Perhaps surprisingly, this approach seems to be better (IMO), for several
83−reasons:
84−
85−1. Brittany cannot guarantee that the output will be “canonical”. With given
86− configuration, if we pass it different inputs expressing identical
87− Haskell programs modulo spacing and indentation, by design it may produce
88− different outputs:
89−
90− ```
91− input0 input1 ... inputN
92− | | |
93− output0 output1 ... outputN
94− ```
95−
96− While with the approach taken by Hindent we get rather this:
97−
98− ```
99− input0 input1 ... inputN
100− | | |
101− \ | /
102− \ | /
103− \ | /
104− \ | /
105− \ | /
106− \ | /
107− canonical output
108− ```
109−
110− Because there is one way to pretty print parsed program. This means that
111− the users won't need to think about the layout at all because it'll be
112− 100% determined by the pretty-printer after the transformation.
113−
114−2. The code is easier to read and debug. Pretty-printing functions are very
115− straightforward. If there is a bug (in pretty-printer, not in parser
116− which Hindent cannot control), it's easy to fix AFAIU.
82+Hindent code is easier to read and debug. Pretty-printing functions are
83+very straightforward. If there is a bug (in pretty-printer, not in parser
84+which Hindent cannot control), it's easy to fix AFAIU.
11785
11886Hindent is also notable for its ability to handle CPP and inputs that do not
11987constitute complete modules. It splits input stream into so-called “code