qualified imports, PVP and so on

[Michael Snoyman]

On Tue, Feb 25, 2014 at 11:12 AM, Herbert Valerio Riedel <hvr at gnu.org>wrote:

> 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`)
>
>
Yes, that's what I meant. I realize now corelibs wasn't the right term, but
I don't think we *have* a correct term for this. I like your usage of
upgradeable.


> 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.
>
>
That situation is technically possible, but highly unlikely to ever occur
in practice. Consider what would have to happen:

foo-1 is released, which works with base 4.5 and 4.6. It has a version
bound base >= 4.5 && < 4.7.
foo-2 is released, which only works with base 4.5. It changes its version
bound to base >= 4.5 && < 4.6.

In other words, a later release of the package would have to drop support
for newer GHCs. The far more likely scenario to occur is where foo-1 simply
didn't include upper bounds, and foo-2 adds them in. In that case, cabal
will try to use foo-1, even though it won't anyway.

Does anyone have an actual example of base or template-haskell upper bounds
that provided benefit?


> 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.
>
>
I'd actually argue that this is a disadvantage. It's true that we want
users to have a good experience, but the *best* experience would be to let
upstream packages get fixed. Imagine a common build error caused by the
removal of `catch` from Prelude in base 4.6. With upper bounds, a user gets
the error message "doesn't work with base 4.6" and reports to the package
maintainer. The package maintainer then needs to download GHC and try to
compile his package before getting any idea what the problem is (if there
even *is* a problem!).

With more verbose errors, a user could give a meaningful error message and,
in many cases, a maintainer would be able to fix the problem without even
needing to download a new version of the compiler.


> 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
>

+1, forcing major version bumps for each new instance just in case someone
has an orphan instance is complete overkill.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140225/a3080ace/attachment-0001.html>