[Hackage] #233: case of Boolean values "true" and "false" should not matter
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The Cabal documentation does not specify the formatting of Boolean values "true" and "false". Hence it seems reasonable to assume that case does not matter, as it does not matter for any field name. However, the ghc- based implementation of Cabal seems to only accept init-caps "True" and "False". -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: worksforme Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by guest): * status: new => closed * resolution: => worksforme Comment: Cabal always accepted both lower-case and capitalized, but never things like "TRue" or "FaLse". It works fine in Cabal HEAD. --Thomas -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: closed => reopened * resolution: worksforme => Comment: 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): Sorry I got that confused with parsing booleans in conditions. The attached patch should fix the issue at least for boolean fields. --Thomas -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: reopened => closed * resolution: => fixed Comment: Patch applied. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: closed => reopened * resolution: fixed => Comment: 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
On 27 mar 2008, at 18.11, Hackage wrote:
#233: case of Boolean values "true" and "false" should not matter ---------------------------- +----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ---------------------------- +----------------------------------------------- Changes (by duncan):
* status: closed => reopened * resolution: fixed =>
Comment:
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'd vote for a warning.
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by ross): 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:6 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 :-) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233#comment:8 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#233: case of Boolean values "true" and "false" should not matter ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: reopened => closed * resolution: => fixed Comment: 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/233#comment:9 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (2)
-
Hackage -
Thomas Schilling