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

[Claus Reinke]

>> What one cannot do (in Haskell 98) is to have two instances of
>> the same class, for the same types, in the same import hierarchy.
> 
> What do you mean by "in the same import hierarchy"?
> Do you mean "in the same program"?

Actually, I was thinking of any import hierarchy with a common root,
but it doesn't make much difference; Haskell'98 only rules this out for 
the whole program, but sub-hierarchies (libraries) with duplicate instances 
can thus never become part of any Haskell'98 program.

> I've put an example showing how multiple instances can cause Data.Set to
> go wrong here:
>    http://hackage.haskell.org/trac/ghc/ticket/2356#comment:8
> 
> Do you think that that behaviour is OK?

Note that I submitted that ticket;-) I think that the behaviour, the 
Haskell'98 vs Ghc discrepancy, the comments, and this thread,
show that the rules need to be specified carefully and clearly, and
that the current situation is not satisfactory.

Such an investigation might have one of several consequences, including:

1 your example is accepted (*), and causes no problem, because
    noone is making assumptions about the instance being the
    same everywhere (one instance implying the absence of others)

2 your example is rejected (*), and alternative solutions are found
    for people who rely on this Ghc behaviour for overlapping
    and other instances (late resolution of overlaps, omitting errors
    if "late" can be pushed after full program compilation)

3 your example generates a warning (*), indicating that Ghc's
    interpretation is at odds with what people might expect
    from the Haskell'98 subset (I would tend to prefer this as
    an interim workaround, until one of 1/2/3 can be decided on)

(*) in Ghc mode; in Haskell'98 mode, it should always cause an 
    error message

>> How do packages make a difference here?
> Generally, you control what other modules in your program do, but not
> what the packages that you depend on do. So if a package you use starts
> using an instance that you don't want, then you are stuck.

Ah, ok. I was assuming that problem for any modules supplied
by others, so packages don't make the situation worse for me
(packages seem neither necessary nor sufficient to worsen the
situation: I might provide my own package, which I could change;
or I might use package-less modules that I can't change directly -
we had that issue with Programatica and Strafunski a while back;-).

Claus