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

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 * 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