On 8/15/12 11:02 PM, MightyByte wrote:
One tool-based way to help with this problem would be to add a flag to Cabal/cabal-install that would cause it to ignore upper bounds.
I'd much rather have a distinction between hard upper bounds ("known to fail with") vs soft upper bounds ("tested with"). Soft upper bounds are good for future proofing, both short- and long-range. So ignoring soft upper bounds is all well and good if things still work. However, there are certainly cases where we have hard upper bounds[1][2][3], and ignoring those is not fine. Circumventing hard upper bounds should require altering the .cabal file, given as getting things to compile will require altering the source code as well. Also, hard upper bounds are good for identifying when there are semantics-altering changes not expressed in the type signatures of an API. Even if relaxing the hard upper bound could allow the code to compile, it is not guaranteed to be correct. The problem with the current policy is that it mandates hard upper bounds as a solution to the problem of libraries not specifying soft upper bounds. This is indeed a tooling problem, but let's identify the problem for what it is: not all upper bounds are created equally, and pretending they are only leads to confusion and pain. [1] Parsec 2 vs 3, for a very long time [2] mtl 1 vs 2, for a brief interim [3] John Lato's iteratee <=0.3 vs >=0.4, for legacy code ... -- Live well, ~wren