patch applied (cabal): Use the same ReadP for all compilers, remove CPP hacks

Duncan Coutts duncan.coutts at
Tue Mar 18 09:20:22 EDT 2008

On Tue, 2008-03-11 at 01:34 +0000, Duncan Coutts wrote:
> On Tue, 2008-03-11 at 00:39 +0000, Ross Paterson wrote:
> > On Mon, Mar 10, 2008 at 05:23:06PM -0700, Duncan Coutts wrote:
> > > Mon Mar 10 12:14:22 PDT 2008  Duncan Coutts <duncan at>
> > >   * Use the same ReadP for all compilers, remove CPP hacks
> > >   If we're bundling a whole copy of ReadP then why bother trying to use
> > >   the version from the base package, especially when that requires hacks
> > >   to use the H98 version with some compilers and the non-H98 version in
> > >   base.
> > 
> > The benefit of using the base version is that ReadP parsers provided by
> > the Cabal library can be combined with parsers using the base version.

So in balance, do you think we should revert to trying to use the base
ReadP where possible then?

> Though we were not always using the base version, with some compilers we
> were using the base one and with other compilers the bundled one.
> I'm rather keen to replace ReadP anyway as the standard parser in Cabal.
> I think we want something that can produce error messages.

I'm still hoping for some guidance on the other issue I raised:

(perhaps I should top-post for more attention)

> Indeed I think lots of bits of the current parser need another look.
> All the enumeration fields are very brittle and do not allow for any
> forwards compatibility. Cabal's current response to adding a new
> compiler, license, build-type, language extension or whatever is to
> just fail with a "parse error in field 'foo' on line N".
> All uses of parseReadS really have to go.


More information about the cabal-devel mailing list