Relaxin the PVP with regards to adding instances

Ben Millwood haskell at benmachine.co.uk
Tue Sep 11 22:51:37 CEST 2012


On Tue, Sep 11, 2012 at 6:04 PM, Michael Sloan <mgsloan at gmail.com> wrote:
> On Tue, Sep 11, 2012 at 5:32 AM, Ben Millwood <haskell at benmachine.co.uk> wrote:
>> On Tue, Sep 11, 2012 at 6:14 AM, Michael Sloan <mgsloan at gmail.com> wrote:
>>> Glad to hear that you agree that it's consistent!  This would make the
>>> PVP simpler.
>>>
>>> I've been thinking, there's still a way to retain the property that
>>> you can specify version bounds which retain compilation, even with
>>> orphan instances.  If your package really needs to add an instance to
>>> a datatype / class exported by some dependency, then you can put an
>>> upper limit on the minor version.  Harsh, I know, but orphans muck
>>> things up any way you slice it.
>>>
>>> This means that any orphans you use, you'd need to explicitly depend
>>> on an A.B.C upper-bounded version of the packages that define the
>>> datatypes (and classes, if you're being entirely correct), and not
>>> consume them through something that re-exports them.  Ideally, this
>>> could be mechanically checked.
>>
>> This seems sensible. However, in case this wasn't already clear, it
>> means when you /add/ an orphan instance, you still need a major
>> version bump: suppose I depend on package A and package B and have an
>> orphan for a type in package B, then you suggest I depend on
>> package-B-minor and package-A-major – so if package A adds an orphan
>> instance, they need to make their version bump major to stop me from
>> breaking.
>
> I actually didn't write down what I meant to - instead of "any orphans
> you use" --> "any orphans you define". [...]

I /think/ that's how I read it, but I might have misunderstood.

> Hmm, I hadn't thought of what you're pointing out!  So, the way to get
> the properties I was going for, even with orphans, is that as soon as
> you define an orphan instance, you must specify minor bounds on every
> package that could realistically want to define their own orphans.
> Definitely not ideal!  I guess the alternative is the "instance
> manifest" solution, and have Cabal use them for resolution (also hairy
> and troublesome)..

No, you only have to specify minor bounds on anyone who could add a
instance /without/ it being an orphan - i.e. the owners of the class
and type. If any of the other packages declared an orphan, they'd
major-bump.

So, in summary:

- adding an instance of a type or class that you control is a minor
(x.y.z) version bump
- adding an orphan instance requires a major version bump, and also
makes you fragile to minor version bumps in the package that defines
the class or type.
- removing an instance ordinary or otherwise still requires a major
version bump, so when an orphan transitions to the original package,
the original package minor-bumps and the orphan package major-bumps,
and code with only a major constraint on both will not break (because
the constraints of the orphan package mean you can either build with
the old version of both or the new version of both).



More information about the Libraries mailing list