case of Boolean values "true" and "false" should not matter

Cabal always accepted both lower-case and capitalized, but never things like "TRue" or "FaLse?". It works fine in Cabal HEAD. --Thomas

Doesn't work for me:

flag foo
  default: false

gives

$ cabal configure
cabal: Foo.cabal:28: Parse of field 'default' failed: 

And this makes sense given the parser being used:

    , simpleField "default"
        (text . show)    parseReadS
        flagDefault      (\val fl -> fl{ flagDefault = val })

parseReadS just uses read so is case sensitive. The buildable field also uses parseReadS as a parser.

I think we have the same problem for other enumerations like build-type, tested-with, license and extensions though it's not so clear in those cases if it should be case sensitive or not.

Sorry I got that confused with parsing booleans in conditions. The attached patch should fix the issue at least for boolean fields. --Thomas

Patch applied.

I'm actually not sure this was the right thing. It creates a forwards compatibility problem.

So currently everyone is using Cabal-1.2 which does not accept "true". Now with this patch, developers will start uploading packages to hackage that contain "true" and all the users of Cabal-1.2 will get very unhelpful parse errors.

We've made a number of changes to the parser recently to make it handle unknown values better, but we've been pretty careful to not make it accept any new values so as not to cause forwards compat problems. Once the majority of people are using Cabal-1.4 or later then it'll be possible to introduce new valid parses without breaking Cabal-1.4.

So I'm inclined to revert this patch, or at least change it so that "true" "false" are accepted but with a warning, and now allowed to be uploaded to hackage.

I think it was a mistake. Try complaining that true and false don't work in a Haskell program.

More generally, there have been a number of ad hoc introductions of case insensitivity; it's not clear what the guiding principles are.

The documentation uses all of "True", "true", "False", and "false", so it seems reasonable to accept them. After all, there is no suggestion anywhere in the docs that any other field values must follow Haskell literal syntax.

Replying to ross:

More generally, there have been a number of ad hoc introductions of case insensitivity;

Have there? Any others in .cabal files?

I know we have made cabal-install accept "haxml" for "HaXml?" on the command line when that does cause ambiguity. That seems user friendly to me.

We also wanted to prevent packages that differ only in case from being uploaded to hackage since we usually have to store package info in file systems and Windows and OS X use case insensitive file systems by default. Also, linux distros often like to lowercase package names and we want to avoid name collisions.

it's not clear what the guiding principles are.

In the short term it's: improving the parser to allow future extensions without breaking existing installations.

Beyond that I'm not sure there are any. Convenience I suppose, though shifting from convenience of implementation (ie ReadS) to convenience for the user (ie permissive parsing and good error messages). Some degree of consistency in syntax would be nice too :-)

Now a warning, for example:

Warning: The 'default' field is case sensitive, use 'True' or 'False'.

So as long as hackage rejects packages with parse warnings this'll work ok.