
On 11/09/2012 18:04, Michael Sloan wrote:
On Tue, Sep 11, 2012 at 5:32 AM, Ben Millwood
wrote: On Tue, Sep 11, 2012 at 6:14 AM, Michael Sloan
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". Using orphans does not cause finer grained upper bounds.
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)..
What's the problem with forcing a major version bump in every release that adds an orphan instance? Ganesh