[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

[wren ng thornton]

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