instance visibility

[Simon Marlow]

Claus Reinke wrote:

>>>> .., the only sensible way to think about instances is as global 
>>>> properties.
>> ..it has nothing to do with bugs or misfeatures in GHC, it's a fact of 
>> Haskell 98.
> 
> I thought my example demonstrated quite clearly that instances are *not* 
> global in Haskell.

Yes, I know that you can limit the visibilty of instances by using 
orphans in Haskell 98.  My point was that it is a mistake to design 
libraries this way, because it leads to a loss of abstraction.

>> This is even worse at the level of packages.  We can hide modules that 
>> are used internally to a package's implementation, but we can't hide 
>> the fact that a package used some non-standard instances internally, 
>> and furthermore we can't change this aspect of its implementation 
>> without changing the API.
> 
> How do packages make a difference here? As long as I don't import
> base:Control.Monad.Error, the base:Control.Monad.Instances instances
> of Functor, say, are not visible in base:Control.Monad.

If I write a package that uses Control.Monad.Instances internally, that 
becomes visible via its API, and I cannot abstract away from this aspect 
of the implementation of my package.  This is an absolute failure of 
abstraction, and if we value abstraction (which we surely do?) then we 
should look for ways to fix the problem.

So one way is to look at changing the language, perhaps by supporting 
explicit re-export of instances.  Certainly that's a worthwhile 
direction to explore, but since our current language doesn't have this 
extension, we have to look for other ways to avoid the problem in the 
meantime.  The only solution is to not have orphan instances in the 
original library API, which is what I'm arguing for.

I think you misunderstood my point before (but you recognised that I 
repeated it :-).  I'm not trying to say that Haskell 98 only supports 
global instances, rather I'm saying we should think of it that way and 
design our libraries with global instances in mind, because otherwise we 
have serious problems with abstraction.

We agree that this is a failure of the language.  You seem to be arguing 
that we should pretend that the language is not broken in the hope that 
it gets fixed in the future - I think that's the wrong approach.

> 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

Right, agreed.

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

I'm not sure what "client libraries" are, but I think I agree, if what 
you're saying is that orphan instances should be kept out of library 
APIs.  I'd also argue that they shouldn't be used in application code 
either, but the reasons are less compelling there.

> My preference would be to see ghc #2182, #2356 (for Haskell 98
> mode) and haddock #54 fixed. #2356 (for Ghc mode) is documented
> behaviour, I believe, inherited from Ghc's handling of overlapping
> instances, but there is no LANGUAGE extension specifying this
> behaviour, so it isn't portable.

I'll just point out that if we stop using orphan instances in library 
APIs, then #2182 is much less of an issue.

> Next, I'd like to see whether more
> control over instance re-export is permissible in theory and -if yes-
> would like to see it implemented and standardised.

Sure, please do!

Cheers,
	Simon