instance visibility (was: Re: The base library and GHC 6.10)
claus.reinke at talk21.com
Wed Sep 24 14:21:19 EDT 2008
>> 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:
> 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
>> 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;-).
More information about the Libraries