Parsec as a Dependency?
simonmarhaskell at gmail.com
Mon Jun 11 05:48:39 EDT 2007
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?
More information about the cabal-devel