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