instance visibility

[Claus Reinke]

> Good!  I completely disagree.

Ok. Since we now agree to disagree on the solution, but seem to
agree on the problem, if not the language used to describe it (sigh:), 
it might be useful to note that our suggested approaches are 
somewhat dual:

A every instance should be available as widely as possible
B no instance should be available more widely than necessary

One consequence of following A is that it doesn't matter whether
an imported module exports instances, because anyone possibly
affected by them will have them anyway. That is less flexible than
B, as A doesn't allow for localised instances, but that limitation
is in line with Haskell'98 and means that the only trouble that can
arise from conflicting instances is that a program doesn't compile.

This means that some code can't be written, because missing
instances can't be added to external libraries, which also means
that there can't be two libraries providing or using different 
instances for a shared class/type.

One consequence of following B is that very fine control over
instance import and export needs to be exercised, with the benefit
that localised instances become thinkable (they have been possible 
in Ghc for some time, but could be put on a less adhoc basis), at the
expense of having to think carefully about possible conflicts arising
from different libraries providing or using different instances for a
shared class/type. 

This means that the current language limitations become very
visible, as they interfere with the fine control of instance re-export,
which also means that it is easy to mess up.

As for orphan instances, approach A forbids them entirely, while 
approach B forbids importing them into libraries (in the present
context, a library module is a module that can be imported). So,
in B, orphan instances can only be imported into applications 
(modules that aren't themselves imported). If one absolutely needs
to combine a library L with some orphan instance module O, one
should provide two versions of L, one with and one without 
importing O.

As for language limitations, approach A tends to adapt to them,
while approach B tends to highlight them.

I hope that summary isn't too biased?-)

>  instance Functor T where fmap = fmapT

Providing default instance method implementations instead of instances
is indeed used in practice, eg Data.Traversable.
 
>> Since libraries@ is the maintainer for Control.Applicative, may
>> I suggest to add Control.Applicative.Alt, differing from the original
>> only in omitting the import of Control.Monad.Instances? Then all
>> importers of Control.Applicative should be checked for whether
>> import of Control.Applicative.Alt is sufficient, and be switched
>> to that if possible.
> 
> That justs moves the problem around, and doesn't fix it.

While giving up Haskell'98 compatibility, as in your suggestion,
cuts the Gordian Knot? I don't think so, but then we tend to
disagree on such things;-) Would anyone else like to venture
an opinion?

Claus