Should the PVP be changed with regards to instances?

Henning Thielemann lemming at henning-thielemann.de
Wed Dec 21 15:18:05 CET 2011


On Wed, 21 Dec 2011, John Lato wrote:

> On Wed, Dec 21, 2011 at 11:26 AM, Henning Thielemann
> <lemming at henning-thielemann.de> 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.



More information about the Libraries mailing list