Relaxin the PVP with regards to adding instances

[Michael Sloan]

I agree that it's quite unfortunate that adding instances causes a
major bump.  I think that instead it would make sense to only bump
your major version whenever you add *orphan* instances.  This is
because it is known to be dangerous to create orphan instances, and
the errors are relatively transparent.  While I suppose it could break
proper dependency resolution, a big reason for upper bounds is
preventing a cascade of confusing errors.  With orphan instances the
errors are very finite.

In general here are a few different things that would help with the
orphans problem:

1) Have a new variety of instance declaration, "orphan instance",
which is suppressed whenever there is a non-orphan instance.

2) Same as #1, but have this behavior be implicit for all instances (I
imagine this'd be unpopular due to it changing Haskell 98, but could
be an extension)

3) Have a centralized orphan registry integrated into Hackage, and
tended by the community.  Package owners can submit their particular
orphans for "canonicalization".  When conflicting instances are
submitted, the package owners would then know about it because they'd
both attempt to register, and then a discussion can happen.  Beyond
the registry itself, implementation-wise this would mean that your
index haddock page would be plastered with some red warning banners
under the conditions that:

  - It contains orphans that have been elsewhere registered
  - It contains orphans that have not been registered

I think #1 and #3 together would greatly lessen the risk of orphan
instances, and might even make the major version bump for adding
orphans unnecessary.

-mgsloan

On Wed, Sep 5, 2012 at 5:22 PM, Evan Laforge <qdunkan at gmail.com> wrote:
>> Assuming no one uses orphan instances, adding instances is always safe
>> because you can only add instances for types from packages you depend
>> on, which means that they can't be depending on your package in turn
>> and have defined a non-orphan instance for a type or class defined in
>> your package.
>
> The thing is if a library is missing some standard instance like
> Monoid it's very tempting to put in your own.  So the instances the
> library author is most likely to eventually add in are also the ones
> people are most likely to have worked around locally by adding their
> own orphans.
>
> E.g. Applicative for Parsec, Monoid for Text.PrettyPrint.Doc.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries