Previously the autoformatter worked fine, and all the pretty-print machinery is quite advanced and robust, but the actual output left some things to be desired, in particular spacing around key-value pairs, chained expressions (fixed in #53), and also it tended to put things on a line when that fits, which does not necessarily make things more readable.
This addresses those shortcomings to the point where I think the formatter now works well enough for real-world files that it is usable in practice.
Furthermore, add a fuzzer to verify the property that format ∘ evaluate(format=rcl) = evaluate(format=rcl); in other words, the value pretty-printer and the CST pretty-printer (the autoformatter) format things in exactly the same way. The fuzzer uncovered some differences at first, but at the time of writing it didn’t find any new counterexamples for over an hour.
To do in a follow-up PR:
Format let-chains (or statements in general) as one per line.
Format binary (n-ary) expressions as one wide/tall group, don’t allow breaking in the middle.
Previously the autoformatter worked fine, and all the pretty-print machinery is quite advanced and robust, but the actual output left some things to be desired, in particular spacing around key-value pairs, chained expressions (fixed in #53), and also it tended to put things on a line when that fits, which does not necessarily make things more readable.
This addresses those shortcomings to the point where I think the formatter now works well enough for real-world files that it is usable in practice.
Furthermore, add a fuzzer to verify the property that
format ∘ evaluate(format=rcl) = evaluate(format=rcl); in other words, the value pretty-printer and the CST pretty-printer (the autoformatter) format things in exactly the same way. The fuzzer uncovered some differences at first, but at the time of writing it didn’t find any new counterexamples for over an hour.To do in a follow-up PR: