Annotationless exact-printer

[BurningWitness]

Potentially closes #7544.

Skeleton parser

Currently able to parse every single manifest stored on Hackage and to render it back into the exact same representation.

Implementation choices:

• All whitespace is treated as spaces;

• Data representation cannot be delayed in either dimension:

  • Not depthwise due to curly bracket syntax;
  • Not breadthwise due to parsec not supporting returning the remainder of the input (parsec is the only available parser, per Meta: Exact-printer Mega-issue #7544 (comment)).

• Curly bracket syntax is treated more leniently than in the lexer (see Meta: Exact-printer Mega-issue #7544 (comment) for examples, all of these are accepted here);

• Trailing whitespace and newlines are preserved everywhere in the format due to curly bracket positions depending on them.

• Fields are allowed to have names with spaces in them, due to the fact that certain extremely old packages allowed that (see e.g. build depends at the very end of smartworld-0.0.0.5). Patches are the current fix to this specific issue, field representation has been narrowed down to exclude spaces.

Further extensions

• Every single currently used field format
• Simple Layout encoding with automatic consistent offset increments
• (?) Lexer compatibility: Layout -> [Field Position]

Discarded ideas

• Streamlined Layout manipulation (e.g. Meta: Exact-printer Mega-issue #7544 (comment))

---

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.

[BurningWitness]

After thinking about it for a while, I do not think helper functions for updating the data structure make sense here. Every use-case has a completely different flow:

• Parsing is collecting all the top-level fields and sections into categories (description, flags, executables, libraries, tests), then resolving categories in order.

• Formatting is going depth-first and changing numbers around;

• Altering build-depends (or any other field) is going breadth-first and finding the first instance of a specific element on each level, quitting early if possible.

On top of this the data structure itself is rather simple, so if someone needs to go from Contents to a Field, they can come up with a specialized function that does what they need.

[BurningWitness]

Note that while this is written using parsec, it should ideally use binary. The draft uses parsec simply because I didn't know binary was an option when I was writing it; additionally using binary would not be seamless, as it currently does not have getUTF8 and match/unsafeMatchLazyText primitives.

---

All of my work on this has stalled back in November.

The first step, which is the exact-printer of the format, works and alone qualifies for a PR. Some minor adjustments could be applied, such as converting to binary or parsing a stream of nodes instead of a list.

The second step would be decoupling every single field format, which turned out to be far more complex. Not only is the Field Syntax poorly documented, currently parsing couples format with implementation: for example Version parses version tags, logs a warning and discards the tags (see here). It is impossible to advance on anything here without a broad agreement on everything prior, and it would most probably fit better in a separate PR.

Consider this draft to be on an indefinite hiatus until feedback arrives.

[andreabedini]

@BurningWitness I just want to thank you for the update and commend you for having a go at this. I had been working on a different approach (that I have so far kept to myself). If I ever put something out, I will ping you.