qualified imports, PVP and so on

[Herbert Valerio Riedel]

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