Meta: Exact-printer Mega-issue

[emilypi]

What is this issue?

A central place to discuss the issue of a Cabal exact-printer so that we can push forward the work all in one place. Currently, The discussion stretches back across many issues over the past 6 years.

What is it?

An exact-printer, as inspired by ghc-exactprint, is a byte-for-byte bidirectional parser and pretty printer, which gaurantees the following constructs exist and are principled:

• A .cabal file source tree representation, which is in bijection with the package description for a .cabal file for a given spec version. This representation should be parametrized with all offset and encoding information along with file data.
• A method for introducing deltas to .cabal file entries. I should able to update and transform individual components of data deep in the representation without modifying the broader structure.
• A pretty printer which adds offset annotations to the specification fragment so that the output should have a byte-for-byte round trip on no-op parse/print and print/parse tests.
• Tests which confirm this in cabal-testsuite and cabal install's test suite for the individual commands.

Why do we need it?

This work is tied very closely with the format, init, gen-bounds and other work as shown in historical discussions:

• RFC: new intermediate cabal file representation. #3614
• WIP/RFC: Parse .cabal files to a source code representation #6621
• Use Distribution.Fields.Pretty in cabal init. #6187
• Make a spec-looking reference implementation of outer grammar. #4965
• etc...

This would free us up for several important quality of life improvements to the cabal install ecosystem, as well as general consumers of the Cabal library API. We would like to have this in by Cabal-3.8.0.0. The important bits this enables include:

• cabal gen-bounds - will be able to update build-depends stanzas in a principled manner, so that bounds management will be automatic in the future if the user so desires.
• cabal format - we hope that a .cabal format can have a canonical shape, so we can limit the amount of deviations from the norm, or ad-hoc formatting choices present in the ecosystem.
• cabal init becomes much easier to manage, and we no longer have to dedicate redundant types, formatting, and pretty printing to this effort.
• Transforming cabal files, with something like module discovery, becomes that much simpler.

Who's in charge of this?

I am currently overseeing @ptkato who has been tasked with taking this on. Please consider him and myself a point of contact for this work, and join us in libera.chat#hackage to discuss.

@ptkato @gbaz @davean

[gbaz]

We have an intermediate "lexed tree" structure in https://github.com/haskell/cabal/blob/1be581d5463adebf8dc8cc8a5375a9ca3051970a/Cabal/src/Distribution/Fields/Field.hs

One idea I would throw out is turning that structure into the main structure we get exactprinting working with (making it comment and whitespace preserving). Then transforms on cabal files involve parsing to that, then running the FieldGrammar parser to get the nice fully typed structure, modifying that and emitting it back to Fields, and then calculating the delta to apply the changes thus made to the original exact Fields.

[emilypi]

There's good prior art here: - https://github.com/phadej/cabal-fmt

[tonymorris]

I've written a few of these for other formats. If you need help @ptkato then @emilypi can hook us up.

[Mikolaj]

See also the old github project about that: https://github.com/haskell/cabal/projects/9

I've updated it with related issues I've found, but then also marked all the issues with a label, so the indexing is available in both forms now. If the project is not going to be used, please remove it. The labeling will remain, preserving the data.