Relaxin the PVP with regards to adding instances

[Michael Sloan]

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 <ross at soi.city.ac.uk> wrote:
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries