On Wed, Jun 30, 2010 at 4:24 PM, Claus Reinke
True. That was an overstatement, based on some particular use cases I happen to care about, and which this proposal would break. But consider 'Either a' as a refinement of Maybe: the proposed new 'Monad (Either a)' instance is not only less defined that the current instance, it is less defined than the existing 'Monad Maybe' instance. Either having more structure to represent information but its Monad instance capturing less information than Maybe makes no sense to me.
But you know more about Maybe, than you do about 'Either a' namely that there is no information in its Nothing/Left alternative. So given just Either a and Maybe, neither subsume the other. You know you can construct an element in the limit of Maybe: Nothing, but you don't know that such an object exists forall a. in Either a. You can make the same statement about particular choices of a. i.e. that Either () might a well be Maybe except for an extra bottom, but the instance head, being Haskell 98 has to be formed "Monad (Either a)" which means that you have to constrain (as mtl does) all Eithers to support such an empty value, or constrain none of them. The version that Ross puts forward is the version that can make sense inside of Base. It fits with the module it is moving into, it doesn't require Base adopting whole-hog the Control.Monad.Error.Class machinery, and it drops a value that is an instance for a prelude type into the class where it belongs. With that change, the mtl is no longer defining instances for any types it doesn't own! Both of these changes feel right from an implementation perspective, even if they come at the cost of a switch to folks leaning on the existing mtl semantics. Already people using the mtl will need to ready themselves for a much similar set of changes involving the constructor names used by all of of State/Reader/Writer etc switching to type aliases around their transformer versions, as mtl becomes an alias for monads-fd + transformers. In that vein it makes sense that the basic error type used by transformer-centric should ALSO be a type alias wrapped around ErrorT, rather than an abuse of a prelude type. -Edward Kmett