instance visibility

[Claus Reinke]

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

Thinking of it that way still doesn't make it so. If you want instances
to be global, you have to change Haskell 98, by propagating instances
through the whole program.

Also, you don't mean "global", you mean "at most one per program".
The latter matches what Haskell'98 does, but not what Ghc does. The
former matches neither, so will lead to trouble in use (just because one
user follows your rule, that doesn't mean everyone does, so anytime
your user imports a not-invented-here library, his model breaks down).

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

I have been arguing that we need to be more precise and explicit
about what is going on, so that we can see exactly in what ways
the language or its implementations are broken and so that we can 
avoid errors arising from mismatched implicit interpretations.

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

Assuming that LT, LC, and LIa/LIb, are libraries that provide type, class,
and two sets of instances, respectively, then using any combination of these 
libraries that does not include both LIs in an application A is fine, using LT/LC 
in a library L is fine, but using any LI in another library is likely to cause trouble 
later (because the LI instances are implicitly re-exported from L, while L's
clients might also have other instances for LT/LC's type and class).

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

Once #2182 is fixed, you will need to implement the basics of this anyway, 
for ghci sessions (where :m -M should remove access to M's instances), 
then we just need to provide some syntax for your implementation!-)

Claus