Their code breaking is punishment for creating an orphan instance instead of sending a patch upstream ;) In theory.. practically speaking that is not always practical to wait for an upstream maintainer to maybe take your patch to add new instances. I have never bumped the major version number just because I added a new instance. So, I guess I am in favor of making the bump a 'suggests' instead of 'requires'. When I bump the major version on something like happstack-server. I then have to update half a dozen other packages to reflect the new version number. And I have to email maintainers of packages like digestive-functors, gitit, etc and tell them to bump their version numbers. Additionally, people packaging happstack for a linux distribution now have to also update a bunch of packages instead of just happstack-server. So, that is a lot of work for myself and others, in the off chance that somebody created an orphan instance. In theory, bumping the major version sounds like the right thing to do. But pragmatically.. it is a bit of a burden sometimes. Especially when compared to the risk of something actually going wrong. - jeremy On Tue, Dec 20, 2011 at 10:32 AM, Ross Paterson wrote:

On Tue, Dec 20, 2011 at 04:12:32PM +0000, Johan Tibell wrote:

...

Introducing new instances is unlikely to break users, as they will only get into trouble if they use orphan instances, which is already asking for trouble!

I don't like orphan instances either, but users often do define instances they perceive as missing.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Tue, 20 Dec 2011, Ganesh Sittampalam wrote:

I'd argue against this: users who write orphan instances typically have no choice, even if they know it's problematic. Contrast this to the fact that we do allow new exports, because a cautious user of the package can avoid problems by explicitly listing what they import.

The clean solution for orphan instances are separate modules that are approved by the maintainers of the concerned class and type. If the instance can be easily added to the package of the class or the package of the type, then it should be added there.

On Tue, 20 Dec 2011, Ganesh Sittampalam wrote:

Agreed, but the situation here is that the no pre-approved solution already exists and the author of something that wants those instances has to decide what to do right away.

The package that provides the orphan instance should define the orphan instance depending on the version of imported packages for the affected class and type. The packages that import the orphan instance package should not need to do such distinctions.

On Tue, 20 Dec 2011, Erik Hesselink wrote:

I'd ask you to follow the PVP here. Problems with duplicate instances are often tricky to resolve, and not something you want to encounter when you're developing (not upgrading dependencies). I've often added orphan instances for types from other packages. Yes, I should (and often do) send these upstream, but I still add them locally. I have to have the instance now, to continue my work, and there's no telling when a new version of the original package will be released. The other option is forking the package, which means I also don't get bugfix updates anymore.

A better option is using a newtype and add the missing instances there.

On 12/20/11 1:24 PM, Erik Hesselink wrote:

I'd ask you to follow the PVP here. Problems with duplicate instances are often tricky to resolve, and not something you want to encounter when you're developing (not upgrading dependencies). I've often added orphan instances for types from other packages. Yes, I should (and often do) send these upstream, but I still add them locally. I have to have the instance now, to continue my work, and there's no telling when a new version of the original package will be released. The other option is forking the package, which means I also don't get bugfix updates anymore.

So in short: I find breakage due to conflicting instances much more annoying than a major version bump.

Agreed with this. And with Ganesh Sittampalam: the solution to the problem of major version changes is automated testing/reporting, not allowing potentially breaking changes in minor versions. Yes orphans are bad, but they can be required as an interim measure (or, with CPP, for backwards compatibility). -- Live well, ~wren

Jeremy Shaw wrote:

On Wed, Dec 21, 2011 at 11:24 AM, wren ng thornton wrote:

...

Agreed with this. And with Ganesh Sittampalam: the solution to the problem of major version changes is automated testing/reporting, not allowing potentially breaking changes in minor versions.

[--snip--]

Let's say the authors of text add a new instance[1]. I can not actually update to that new version of text until all the other libraries I use that depend on it are updated. For a very popular library, like text, than can take awhile. So, I am stuck with the old version until everybody updates -- and probably all they are going to do is bump the version range.

One of the major problems here, I find, is the fact that packages that your package depends on *but which are not part of the API to your package exposes to the world* lead to conflicts. (I this solvable currently? Perhaps one can create both an *-api package and a *-impl package?) [--snip--]

Alternatively, a system where libraries exported some sort of declaration of the API they need, so that the PVP is irrelevant would be nice too -- if such a thing could be made to work. The core issue is, after all, that we basically have a single bit of information that we use to declare that the API is changed. That is obviously not very fine grained...

Separation of what the package API actually *is* versus what it uses internally would be extremely desirable. I usually find that it's actually "implementation" dependencies that get me into trouble with dependency management. I realize that it may not exactly be a trivial proposition to implement something like this, but AFAICT .cabal files actually contain enough information to (theoretically at least) be able to implement this.