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

[Duncan Coutts]

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 haskell.org>
> >   * 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.

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.

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.

One idea is to add an extra catch-all onto these enums, like:

data CompilerFlavour =
    ...
  | UnknownCompiler String

then we check for such unknown values and warn about them and do not
allow them to be uploaded to hackage. When we add new enum values, older
Cabal versions will treat the value as other/unknown and where possible
carry on with just a warning. Where it's not possible to carry on with
an unknown value it can fail with a more helpful error message.

Another alternative is to keep only known values in the enumeration but
do something more generic in the parser to represent unknown or failed
values. However that still leaves the problem of what to do when we
encounter unknown values. How they're handled really depends on the
type. New compilers or OSs mentioned in configurations are ok, where as
new build-types cannot be handled.

Any other suggestions?

One way or another I think the plan for Cabal 1.4 should be to make the
parser for these things more liberal but not to accept any new values so
that we do not break older Cabal versions by adding .cabal files to
hackage that older Cabal cannot parse. When enough time has passed and
the current Cabal-1.4 and later are the norm, it'll be possible to add
new enum values without causing major breakage.

Duncan