As noted elsewhere, we've been running into problems with Haskell's "fine" handling of instances while trying to combine some largish Haskell projects. As long as the language isn't changed, this problem needs to be accounted for in library designs.

Concrete examples: Control.Monad.Error, Control.Monad.Reader

A meta point: as far as I'm concerned, the design of any library that is marked "experimental" (see the top of the page for each module in the Haddock docs) is up for grabs. Come up with a proposal, and if there's a concensus it goes in. (all the Control.Monad.* libraries are marked experimental, BTW).

These modules define lots of instances for (Either a) and ((->) a). Why? Obviously, they want to use them, but that's no excuse.

Both Either and (->) are very popular type constructors, and currently, every project that wants to use these instances defines them somewhere. Result: as soon as you put two of these projects together, you get a clash!

In current Haskell, defining instances of public classes for public types/constructors has side-effects running through the whole of any program using such a library. Quite apart from the facts that the module names typically gives no indication of these side-effects, and that the modules could have been implemented without them (using standard types/constructors was just more convenient), there's no way to get two such modules to work together in a larger project without changing them!

IMO, given the current design of Haskell 98, instances should be considered to be global. There is only room for one instance for each type/class pair in any program (including the libraries). Otherwise the library documentation has to publish for each module, a list of all the instances defined by it and all modules below it in the dependency tree. I think this is just silly. If the library defines a particular instance, then you can't redefine it. (interesting bits snipped)

ShowFunctions.hs would have been an example of this (where did that go, btw?).

Text.Show.Functions, of course ;-) (more interesting bits snipped)

PS. perhaps this suggestion got lost in the other thread, but could Haddock please show the source of any instances in the generated documentation?

Showing the source of each instance isn't enough. You need to list each module that exports it. That includes every module which depends, directly or indirectly, on the module that defines it. I *really* don't want to do this - every module in the Haddock docs is going to have a huge list of irrelevant instances attached to it. I could put them in a separate page, but it's still a pain. While correct, this is going to be quite unwieldy. But there's no getting away from the fact that you still need to know which module to import in order to gain access to a particular instance. Cheers, Simon