[sorry for not following this list closely, hope this interjection is appropriate..] given this recent excitement about Control.Monad and transformers, this might be a good opportunity to point to a previous thread here: http://haskell.org/pipermail/libraries/2002-November/000714.html Have these problems been addressed yet, i.e.: - separating standard instances of common classes for common types from other stuff, unlike in the Monad hierarchy (which surprisingly adds instances of Functor/Monad for Either and ((->)a) just because those happen to be one way to implement Errors and Environments), As Haskell doesn't have parameterized modules, my preference would be to single out such instances (and only those which are unambiguously standard) in separate modules, which should make their contents obvious, and which could be imported by any other module needing these instances (without getting other stuff as well) *and wishing to export them*. - not stealing, e.g., the Monad instance for Either in Control.Monad.Error, for a not-quite standard definition. My preference would be use of newtype to define, e.g., an abstract type in terms of Either, and to have the instances defined for that abstract type. Haskell's module system gives no control over instances, but does give control over types. That is, there would be one module providing, e.g., reader monads *without* ursurping instances of "global" classes for "global" types for that purpose, and *another* module providing "standard" instances for "global" classes/types. The latter would be good for quick hacks, the former for modular development - different purposes, different modules. Otherwise, there are conflicts when one combines two packages trying to define their own versions of these instances as part of whatever else they are trying to do (such as the Monad modules right now). There seemed to be some support for these suggestions last time, and as there seems to be a maintainer around now, this might be a good time to fix these things?-) Cheers, Claus