That's a very good point! It is definitely nicer to be able to rely
on these sort of properties when using version numbers. Thanks for
setting that straight!
I've also realized the reason that solutions #1 and #2 are mostly
foolish - you cannot rely on the non-orphan library instance doing
what the client module expects. It could make sense for the user of
the library to declare an "orphan instance" when they believe that any
reasonable library definition would be equivalent.
Thanks!
-mgsloan
On Thu, Sep 6, 2012 at 12:34 AM, Ross Paterson
On Thu, Sep 06, 2012 at 06:01:44AM +0100, Michael Sloan wrote:
Thing is, that if this is the design goal of the PVP, then _any_ addition to the exports of a module should necessitate a major version bump, because of the potential for clashing unqualified, non-explicit imports.
You can make you code proof against additional exports by using explicit imports, which is why they only need a minor version bump. But there's no way to control the import of instances. The typical issue is that you add a type or class, and your users want an instance you didn't provide, so they define one, which will be broken when you add the instance in the next version. You may blame the users for defining the orphan instance, but they had little choice.
The principle should be: - code that built against a particular version of a package will also build against any release with the same major version. - code using explicit imports that built against a particular version of a package will also build against any release with the same minor version.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries