packages with orphaned instances only

[Henning Thielemann]

Simon Marlow schrieb:
> On 07/01/2011 13:14, Ivan Lazar Miljenovic wrote:
>> On 7 January 2011 23:07, Stephen Tetley<stephen.tetley at gmail.com>  wrote:
>>> On 7 January 2011 10:22, Christian Maeder<Christian.Maeder at dfki.de> 
>>> wrote:
>>>
>>>> So is this a bad idea?
>>>
>>> It sounds like a good idea to me.
>>>
>>> There might be some details to trash out, e.g. the granularity of
>>> packages - should there be a Quickcheck-orphans with Arbitrary
>>> instances for many structures, or separate packages
>>> (quickcheck-containers-instances, quickcheck-array-instances, ...) and
>>> perhaps a new top-level Hackage category is needed so people know
>>> where to find them - "Canonical instances", "Orphan instances", ...?
>>
>> My biggest problem with "official" instances such as these is that
>> they may not do what you want.  For example, I have a lot of problems
>> with the testsuite for graphviz because the default list (and hence
>> String) instances do not match the behaviour required, so I have to be
>> careful to make sure I use my custom arbString, etc. functions rather
>> than directly calling arbitrary.

If there are multiple equally natural instances, then there should not
be one at all.

>> That said, if these packages have one-instance-per-module (as in
>> separate modules defining the Arbitrary instances for Map, Set, etc.)
>> then this situation is greatly reduced, since if I want a custom Map
>> instance I just have to make sure I don't import the module that
>> provides the default one.
> 
> Attempting to limit instance visibility is folly, unless you control the
> complete set of modules in your program.  In practice you don't control
> the complete set of modules in your program, because some of them come
> from libraries, and you have no control over what the author of that
> library decides to import in the future.
> 
> It's tempting to think that it's ok to add an orphan instance to a
> program, on the grounds that it's not a library and nobody can import
> it.  But this is dangerous too: the program might break in the future
> when a conflicting instance is added to another library.  You can't
> protect against this breakage by being careful with Cabal dependencies,
> because versions aren't bumped when new instances leak from dependencies
> lower down (and to try to enforce this in the PVP would be impossible).
> 
> So, orphan instances are only sensible when we expect that everyone
> wants to use the same one.  So Christian's suggestion is actually
> reasonable: if we must have orphan instances, make it so that everyone
> can easily use the same one, by putting them in a separate package.

+1  It cannot be said often enough.

Although we have already:
  http://www.haskell.org/haskellwiki/Multiple_instances