[Hackage] #725: Distinguish speculative and required build-depends upper bound

Hackage cvs-ghc at haskell.org
Sun Aug 22 11:30:11 EDT 2010

#725: Distinguish speculative and required build-depends upper bound
  Reporter:  ezyang              |        Owner:         
      Type:  enhancement         |       Status:  new    
  Priority:  normal              |    Milestone:         
 Component:  cabal-install tool  |      Version:
  Severity:  normal              |     Keywords:         
Difficulty:  unknown             |   Ghcversion:         
  Platform:                      |  

Comment(by wk):

 > Recording this extra information in the context of hackage is much

 I don't understand exactly what you mean, but it seems to exclude
 recording this "extra information" for unpublished packages and local

  > For one thing it can be discovered automatically.

 You can discover automatically whether it compiles.
 You cannot, in general, discover automatically whether it works correctly.

  > Adding this information to .cabal files is more tricky, we need a
 syntax for it and users have to specify it.

 I don't think the syntax question is tricky --- if you know the semantics
 you want to enable, you have tons of options.

 One particularly easy option would interpret the current ranges as
 establishing mappings to {{{KnownToWork}}}, and add a separate notation
 (perhaps using a {{{!}}} prefix) to establish mappings to
 {{{KnownToBreak}}}. Versions not mentioned in either would be interpreted
 as being mapped to {{{UnKnown}}}.

 I estimate that most currently-listed excluded upper bounds are intended
 to mean {{{UnKnown}}} and not {{{KnownToBreak}}}. Therefore, this would
 even be backwards-compatible.

 (The semantics of sequences of such positive or negative ranges would most
 naturally be {{{Map.foldWithKey Map.insert}}}, that is, a right-biased
 version of {{{Map.union}}}.)

 If {{{UnKnown}}} gives rise only to a warning instead of to a refusal to
 even attempt compilation (as it does now), that will make it also much
 easier for package authors to be honest about old versions they did not
 check against.


Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/725#comment:5>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

More information about the cabal-devel mailing list