> Oh I'm curious why you're rewriting it?The primary driver is that we're moving to a fairly different formatting style: https://github.com/dart-lang/dart_style/issues/1253
The formatter works sort of like a compiler in that it parses the code, translates it to an internal representation, does optimization on that IR, and then outputs final code. The main difference is that the "final code" is also source code, and the "optimization" is line splitting.
The old IR grew organically over time and got increasingly difficult to work with. It baked certain formatting choices directly into the IR (mainly indentation) which line splitting then had no control over. For example, given a function call like:
someLongFunctionName(some + long + argument + expression, [firstElement, anotherElement, aThirdElement]);
We might want to format it like this if the function name and first argument fits on one line:
someLongFunctionName(some + long + argument + expression, [
firstElement,
anotherElement,
aThirdElement
]);
But if the first argument doesn't fit, then we probably want:
someLongFunctionName(
some + long + argument + expression,
[
firstElement,
anotherElement,
aThirdElement
]);
Note how the indentation of the list elements depends on how we choose to line split the argument list. The old formatter's IR just couldn't model that at all.
For years, I've wanted a better IR that could express formatting like this. And since we were making sweeping changes to the formatting style (including some that would be very hard to implement with the old IR), it seemed like the right time to move to a new internal representation too.
> What do you think of the functional "pretty printing languages" like Wadler's (cited in the blog post)?
I have to confess that I worked on dartfmt for a few years before I stumbled onto that paper. I'm somewhat familiar with it, but I've never taken the time to really dig into it.
I could be wrong, but I strongly suspect that the formatting rules we want for Dart are too complex to model using Wadler's formalism directly, and I'm not sure if extending it to support the formatting rules we want would sacrifice its simplicity or performance.
Given that, I sort of stuck with the devil I already knew—dartfmt's current architecture—and built off of that.
> it does seem like there is a lot of labor in encoding the "rules people like", and flags for different styles. And then there's the actual algorithm to find the line breaks.
Yes, and the two are deeply intertwined. The majority of dartfmt's code by line count is just implementing the style rules for every part of the language grammar. The most difficult code to write and maintain in dartfmt is the line splitting algorithm, largely because it's combinatorial when done naïvely.