On Wed, 21 Dec 2011, John Lato wrote:

On Wed, Dec 21, 2011 at 11:16 AM, Henning Thielemann wrote:

...

On Wed, 21 Dec 2011, John Lato wrote:

...

I'm in the same situation, however I'm quite hesitant to add new instances in a minor version.  Adding new dependencies can cause breakage even without orphan instances, if downstream packages import a different version of that dependency already.

The proposal was about adding type class instances, not about adding package dependencies.

IME, new type class instances usually arise only because of new package dependencies or a major version bump to an existing dependency, either of which would currently require a major bump.

Adding a package dependency does not require a minor version bump. Increasing the imported version of a package dependency only requires a version bump if that changes the API. Thus I do not see a closer connection between adding instances and modifying package dependencies.

On Wed, 21 Dec 2011, John Lato wrote:

On Wed, Dec 21, 2011 at 11:26 AM, Henning Thielemann wrote:

...

Adding a package dependency does not require a minor version bump. Increasing the imported version of a package dependency only requires a version bump if that changes the API. Thus I do not see a closer connection between adding instances and modifying package dependencies.

I'm not sure exactly what you mean here. I suspect it's either:

1. The discussion is about adding new instances only, there's no need to add new package dependencies.

yes

2. Modifying package dependencies is orthogonal to adding instances to a package.

yes

If 1, I agree it's possible to add a new instance that was previously undeclared. I just think that's much less likely than wanting to add an instance for a class from a new package.

I have no numbers for the occurrences. My latest experience was that I proposed a monoid instance for the Parsec monad. The maintainer (Antoine Latter) objected that there are multiple ways to define a sensible Monoid instance and thus left the instance undefined. I think that is the best thing to do in this case. The general situation may be that someone did not add an instance, because it is not obvious what instance to add. After some time of usage of the package it might become clear that one instance is more useful than another one and then it will be added.

If 2, you're correct in a limited sense. But any time you add a new package dependency you transitively get all of its instances. While this may not necessarily add new instances to your package, it certainly has the potential to do so. Besides, I was considering the case of modifying package dependencies specifically to change the API (via new instances).

Do you check for new instances every time you add a new dependency to a package? If not, how do you know that the API hasn't changed?

I did not check, because I expected that there no problems if orphan instances are absent.

Also consider that instances can be written with type variables. This can lead to overlapping instances (breaking compilation) without involving orphans or otherwise dodgy code.

I have not thought about that, so far. You mean something like module A where instance C A b ... module B where instance C a B ... module Z where import A import B ? It would need at least FlexibleInstances. I think they are not as discouraged as orphan instances. Indeed this makes things complicated.