@@ -79,41 +79,9 @@ attempt to build a document representation to render
79afterwards, instead it just prints the parsed code straight away. This means
79afterwards, instead it just prints the parsed code straight away. This means
80that the 70-80% of what the code does is a printing traversal.
80that the 70-80% of what the code does is a printing traversal.
82−Perhaps surprisingly, this approach seems to be better (IMO), for several
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
91− input0 input1 ... inputN
93− output0 output1 ... outputN
96− While with the approach taken by Hindent we get rather this:
99− input0 input1 ... inputN
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.
114−2. The code is easier to read and debug. Pretty-printing functions are very
82+Hindent code is easier to read and debug. Pretty-printing functions are
115− straightforward. If there is a bug (in pretty-printer, not in parser
83+very straightforward. If there is a bug (in pretty-printer, not in parser
116− which Hindent cannot control), it's easy to fix AFAIU.
84+which Hindent cannot control), it's easy to fix AFAIU.
118Hindent is also notable for its ability to handle CPP and inputs that do not
86Hindent is also notable for its ability to handle CPP and inputs that do not
119constitute complete modules. It splits input stream into so-called “code
87constitute complete modules. It splits input stream into so-called “code