Trade-offs for supporting code formatting

[avh4]

I had proposed a tentative plan for code formatting, following the architecture used by elm-format, which consists of five major pieces:

Low-level formatting primitives

Planned to be extracted into a stand-alone Haskell package from https://github.com/avh4/elm-format/blob/recursion-scheme-format/elm-format-lib/src/Box.hs

Language-specific formatting

This is just a function from gren AST -> low-level formatting primitives (or, more accurately, one such function for each node type that's part of the AST). It can be copied from elm-format and then stripped-down and modified.

CLI

Can either be copied from elm-format and modified, or just re-written to fit gren's CLI (there's really not much code to this). (For reference, ElmFormat.Cli.hs)

Test suite

elm-format has a pretty comprehensive integration test suite. I think that's worth trying to have, but I'm not 100% sure the best approach. Probably copying elm-format's test suite and condensing it down might be best (since it's currently, while comprehensive, not very well organized). (For reference, elm-format's integration tests)

Parser

I think this is where the biggest questions are. The language-specific formatting part is going to need an AST that has comments and (some) whitespace information retained. elm-format has a parser that was forked from elm-compiler and had to be heavily modified to retain that information, which has been the biggest maintenance burden for elm-format.

However, elm-compiler has good reason to not retain the extra information, because discarding it pretty certainly improves the speed of the compiler. (Though I don't think that has ever been verified with measurements; and especially with Elm 0.19's new parsing approach that vastly reduce memory allocations while parsing, maybe that wouldn't actually be an issue?)

Possible options:

• add whitespace/comments retention to the compiler's parser (maybe the performance penalty isn't that bad?)
• have a separate, parallel, parser that does retain whitespace/comments
• have some way to parameterize the parser (and AST type) to either retain whitespace/comments or not (is there a good way to do this that wouldn't impact the performance of the no-whitespace/comments parser?)

[avh4]

I think we've settled on an approach which seems to be working. Implementation progress is tracked in #42