On 2014-02-25 at 07:44:45 +0100, Michael Snoyman wrote: [...]
* I know that back in the base 3/4 transition there was good reason for upper bounds on base. Today, it makes almost no sense: it simply prevents cabal from even *trying* to perform a compilation. Same goes with libraries like array and template-haskell, which make up most of the issue with testing of GHC 7.8 Stackage builds[3]. Can any PVP proponent explain why these upper bounds still help us on corelibs?
I assume by 'corelibs' you mean the set of non-upgradeble libs, i.e. those tied to the compiler version? (E.g. `bytestring` would be upgradeable, as opposed to `base` or `template-haskell`) Well, `base` (together with the other few non-upgradeable libs) is indeed a special case; also, in `base` usually care is taken to avoid semantic changes (not visible at the type-signature level), so an upper bound doesn't gain that much in terms of protecting against semantic breakages. Otoh, the situation changes if you have a library where you have different versions, which are tied to different version ranges of base, where you want Cabal to select the matching version. Admittedly, this is a special case for when use of MIN_VERSION_base() wouldn't suffice, but I wanted to give an example exploiting upper-bounds on the `base` lib. There's one other possible minor benefit I can think of, that upper bounds give over compile-errors, which is a more user-friendly message, to point to the reason of the failure, instead of requiring you guess what the actual cause of the compile-error was. But for non-upgradeable packages such as `base`, which do big major version jumps for almost every release (mostly due to changes in GHC modules exposing internals or adding type-class instances[1]), erring on the confusing-compile-error side seems to provide more value. So, as for `base` I mostly agree, that there seems to be little benefit for upper bounds, *unless* a base3/4 situation comes up again in the future. So, I'd suggest (for those who don't want to follow PVP with `base`) to keep using at least a "super"-major upper bound, such as 'base < 5' to leave a door open for such an eventuality. Cheers, hvr [1]: I'd argue (but I'd need research this, to back this up with numbers), that we're often suffering from the PVP, because it requires us to perform major-version jumps mostly due to typeclasses, in order to protect against conflicts with possible non-hideable orphan-instances; and that (as some have suggested in past already), we might want to reconsider requiring only a minor bump on instance-additions, and discourage the orphan-instance business by requiring those packages to have tighter-than-major upper-bounds