Parsec as a Dependency?

[Simon Marlow]

Thomas Schilling wrote:
> Hi Caballers,
> 
> now that .cabal files are getting a more complex syntax (due to
> configurations), I'd really like to use Parsec instead of lots of
> hand-written and hard to maintain parsing code.  By getting rid of
> ReadP-based field parsing, we'd also get proper error messages for
> field values.
> 
> At the Parsec homepage I says that it's now included by default in
> GHC, Hugs and NHC, so it'll most likely be present on any sufficiently
> recent system.
> 
> What would be arguments against this proposal?

I've wondered about this myself.  ReadP is quite annoying, I believe the only 
reason it was used originally was because it was in the base package, and hence 
didn't add any new dependencies.  Unfortunately the portable version of ReadP is 
  quite a pain to use.

Adding parsec as a dependency is a big step - it would bring parsec into GHC's 
core packages, and force its distribution with other compilers too.  I'm not 
completely against this, but we should explore alternatives first.

Maybe a better solution would be to bring in a simple monadic parser combinator 
library.  Malcolm Wallace has offered to relicense his 
Text.ParserCombinators.Poly from LGPL to BSD3 for use in Cabal, this might be a 
good option for us.  Any other ideas?

Cheers,
	Simon