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@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@haskell.org http://www.haskell.org/mailman/listinfo/libraries