Switch to more modern parsing/pretty-printing libraries

[taktoa]

You guys currently depend on parsec and pretty for parsing and pretty-printing respectively. Assuming that you are not doing this purely as a way of minimizing your dependency footprint (since pretty at least is a boot package that ships with GHC), I would recommend that you migrate to more modern parsing/pretty-printing libraries. These can improve parsing speed, parser error message readability, and code reusability.

For parsers, there are two main options, depending on what matters to you:

• If speed is important, then you should use the parsers library to write a typeclass-generic parser, which can then be instantiated with a concrete parser type from trifecta when debugging (trifecta is slow but has good error messages) or with a parser type from attoparsec in production (attoparsec is fast but has bad error messages).
• If nice error messages are important and you want to migrate from your parsec parser easily, but speed is not particularly important, megaparsec is a good option. In the version 6 and above of megaparsec, primitives are provided that make it as fast as attoparsec.

For pretty-printers, my main recommendation is prettyprinter, which is a pretty comprehensive replacement for all the pre-existing pretty-printing libraries in Haskell. It supports terminal output with ANSI colors, HTML output, it doesn't have name clashes with common operators, and it uses Text for performance.

[dlthomas]

So far as I'm aware, parsing speed hasn't been an issue. Moving to megaparsec might be good, but should be weighed against "if it ain't broke" (it was fairly new when the project started, and there hasn't been enough of an impetus to switch).

As to pretty printing, that's presently mostly unimplemented; I don't expect there would be any objection to switching away from pretty if it came with a diff that did more.

[dlthomas]

Two other notes:

1. Choice of parsing library could be per-dialect with minimal drawbacks, so migration could be gradual or limited to new packages (or not - just worth noting we have the flexibility)
2. A much more interesting change to parsing would be something that could handle incomplete statements, but that's also a much bigger change generally.

[Fuuzetsu]

uu-parsinglib has error-correcting facilities, depending on what kind of incomplete statements you're after, this might be something to consider