instance visibility (was: Re: The base library and GHC 6.10)

[David Roundy]

On Wed, Sep 24, 2008 at 05:30:27PM +0100, Claus Reinke wrote:
>> Orphan instances are usually wrong unless the orphans are also exported 
>> via the standard API for either the class or the type.  That is, 
>> orphans are ok in the implementation of a package, but not in the 
>> exposed API, because that makes it possible for a client to import both 
>> the class and type without getting the instance, which is what we have 
>> to avoid.
>
> Sadly, that has all been discussed to death already, and again, it is a  
> matter of being precise. "Orphan" instances are not wrong per se - they 
> encode and name the extent of type relations via modules, but one needs 
> to think carefully about their intended use and whether that use is  
> really supported by the language or just an illusion. Of the top of my  
> head, I can think of two uses:
>
> (a) having two instances of the same class for the same types in the    
> same program only works by "virtue" of #2356, so should be
>    avoided unless and until the positive aspects of #2356 are moved
>    from accident to design decision
>
> (b) giving clients control over which instances they want to use (eg,
>    use set A or set B, or neither) should work, and mostly does,
>    but may run into ghc #2182 and haddock #54. Also, it is    advisable 
> only for client applications, not for client libraries, as    long as 
> their users might run into unresolved aspect of (a).

In the interest of providing a concrete example, see the darcs bug:

http://bugs.darcs.net/issue387

It's a wishlist bug that we can't implement because the Show instance
for Control.Exception.Exception is *not* an orphan (and thus we cannot
define a duplicate instance).  If it were an orphan, we could define a
second show instance and then we'd get an error message if anyone ever
calls show on an exception (which is always a bug).  Alas, we cannot
do this, and so we're stuck perpetually auditing our code to ensure
that noone calls this pernicious function.

Admittedly, we only want this orphan instance as a workaround for a
poor API.  Nevertheless, I think it illustrates your point that orphan
instances could be useful, *particularly* because we have very little
control over instance propogation.

David