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