packages with orphaned instances only

[Simon Marlow]

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.
>
> 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.

Cheers,
	Simon