Source-location aware parser for package descriptions

[dag]

It would be nice if Cabal included a parser for .cabal files that remembers line and column numbers for parsed entities. This could then be used by tools like packdeps to give the source location for an outdated dependency, and in turn used in text editors to annotate lines with information from packdeps when editing a .cabal file.

More broadly, it would be nice to have an exact-printer for the relevant AST, to make it possible to write tools that process .cabal files programmatically without messing up their formatting.

[UnkindPartition]

This (an exact parser/printer) is something I would also like to see.

I may work on it eventually, but it's not high on my priority list.

[23Skidoo]

It would be also nice to have the same for config files.

[dcoutts]

I have a new parser (for .cabal files and config files). The only problem is it needs parsec which currently we cannot depend on because it causes problems for GHC. There is however a plan to get GHC to not depend on Cabal, or rather have the ghc lib not depend on Cabal, only ghc-pkg & the build system. This may allow us to depend on parsec and so we could have a fast and nice new parser.

[dag]

A silly thought: is ReadP too weak for this?

[dcoutts]

ReadP is what we use now. It's terrible. It has no error reporting and no source locations. It's also slow.

[byorgey]

@dcoutts: Exciting! (A patient sort of excitement.)

[erikd]

I understand why we can't currently use Parsec for tthis, but would it be possible to use alex and happy? Obviously not as elegant as Parsec but probably better than ReadP.