Relaxin the PVP with regards to adding instances

Michael Sloan mgsloan at
Thu Sep 6 07:01:44 CEST 2012

Thing is, that if this is the design goal of the PVP, then _any_
addition to the exports of a module should necessitate a major version
bump, because of the potential for clashing unqualified, non-explicit
imports.  The reasoning for this seems to be that the chances are low
(very context dependent) and unqualified, non-explicit imports are
discouraged and bad style.  Orphan instances are also discouraged, so
for consistency with the policy for regular additions, it would make
sense for libraries adding instances to only necessitate a minor
version bump.

I don't think that commenting out an instance in bar should really be
considered "developing" bar.  Certainly anyone that wants to stay on
the bleeding edge of ghc or cabal is going to need to get their hands
dirty now and then.  I'd prefer this relatively rare circumstance to
the frequent, painful circumstance where upper bounds are too
restrictive.  Editing version bounds is certainly as invasive as
commenting out an instance, and more opaque to those not well versed
in cabal-foo.

As I've expressed elsewhere, I think there are a bunch of things that
could alleviate dependency hell to varying degrees.  These are just
stop-gaps / changes to conventions in the meantime.  Right now it's
pretty bearable - hackage is bigger - but not giant.  People are doing
stuff - but packages aren't being updated every minute.  I'd like to
see a solution that works well, giving client assurance of
compatibility, while giving library designers freedom to change.  If
this isn't figured out well, things're going to get a lot uglier
during the exponential part of Haskell's (optimistically) anticipated
"hockey-stick" growth.


On Wed, Sep 5, 2012 at 6:07 PM, Ian Lynagh <igloo at> wrote:
> On Wed, Sep 05, 2012 at 05:43:04PM -0700, Michael Sloan wrote:
>> While I suppose it could break
>> proper dependency resolution, a big reason for upper bounds is
>> preventing a cascade of confusing errors.  With orphan instances the
>> errors are very finite.
> I don't think the type of errors was a factor in designing the PvP. The
> primary (perhaps even only) goal was to design packages in such a way
> that if "cabal install foo" would have worked yesterday, then it will
> also work today.
> That means that if foo depends on bar, and there is a suitable newer
> version of bar available today, then foo had better work with that
> version too.
> The person installing foo isn't interested in developing foo or bar, so
> doesn't want any error at all!
> Thanks
> Ian
> _______________________________________________
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list