Advance notice that I'd like to make Cabal depend on parsec

[Duncan Coutts]

On Thu, 2013-03-14 at 21:29 +0200, Roman Cheplyaka wrote:
> * Duncan Coutts <duncan.coutts at googlemail.com> [2013-03-14 17:12:14+0000]
> > The InstalledPackageInfo and its parser is what ghc and ghc-pkg
> > primarily use (though there's the opportunity to share code for handling
> > package indexes) and that type and that parser are also going to end up
> > using text and parsec etc.
> 
> Correct me if I'm wrong, but isn't it just a strange coincidence that
> InstalledPackageInfo is serialised in the format similar to .cabal
> format?

It's not a very strange coincidence. The type is not specific to ghc,
it's defined in a compiler-neutral way by the original Cabal spec. So
since both the source package and installed package info was defined in
the Cabal spec, using the same kind of external syntax and sharing many
of the same types, then they both ended up in the Cabal lib and share
the same parsers & pretty printers.

> InstalledPackageInfos aren't supposed to be edited by hand and do not
> need good error reporting. They can be serialized using any
> serialization library.

Right, it doesn't need good error reporting (though it's nice if it's
fast, which it isn't currently). The main advantage of the current
arrangement is that the source and installed package descriptions get to
share the same types and parser/pretty printer.

I think there's a slightly more general point here though. Why is it
that we don't have any good parser in the core packages? It's not just
Cabal that needs to parse things. We have two useless parsers in the
base package, ReadS and ReadP. Haskell is famous for its parser
combinators and yet our core infrastructure is stuck with only useless
ones!

Duncan