The proposal is to move the Monad and MonadFix instances for Either (currently in the mtl package) to Control.Monad.Instances and Control.Monad.Fix respectively (both in the base package). The Monad instance is still an orphan, to retain Haskell 98 compatibility, but the MonadFix instance is together with its class. The Error constraint is removed from both instances, and the default definition of fail is used.
-1, because the default definition of fail is error, which would render the Monad instance useless (unless I'm missing something?).
Note that my opposition is against making 'Monad (Either a)' less defined and less tunable than it is at the moment. One could also wonder whether the instance should be in Data.Either (the instance for Maybe is in Data.Maybe), whether mtl should simply be changed to use something other than Either, so that mtl's Either-variant and its MonadError instances could remain together, or what the effect of removing Error and moving the 'Monad (Either a)' instance would be on the remainder of mtl's code. To those '+1' fans: please compare what the proposal actually does to what you would like to see. Most of us have had bad experiences with these instances or with Haskell's instance import behaviour (my own complaints go back to 2003 or so). So most of us are happy to see something move. But fixing a less defined 'Monad (Either a)' instance even higher in the package hierarchy is not going to help. Do Ross and us all a favour and study his proposal and the consequences before voting. |A reasonable case can be made for the existence of a monad that does |something useful with fail. Every Monad should try to do its best with fail. If, at some point, fail in Monad gets replaced with throwError in MonadError, or with mzero in MonadZero, or with something else, we can ignore fail in Monad, but I would still expect pattern match error via fail to integrate well with at least one of MonadPlus or MonadError. |I don't think that that monad should be Either. |'Either' takes on the connotation of being the 'sum type' for the category |of Haskell types. This sum type has a very well formed and simple monad, |that has a lot of useful theoretical properties, and is useful in a strictly |larger array of scenarios than the monad with the error constraint, with |the one notable exception that it doesn't handle the 'fail' property that |was bolted into Monad in Haskell 98. Remember that we are talking about Haskell, not category theory. If you want to define a duplicate of Either with additional properties, go ahead. But don't forget to duplicate the existing Either libraries. If Haskell had parameterized modules, we could pass our choice of Either-alternative to both mtl's modules and Either libraries, and everone could be happy. As long as we don't have that option, I don't see why Haskell's sum type cannot have a useful fail. If you are just concerned about the Error constraint, simply provide a default instance that maps strMsg to error (see example of default instances with user override in base Data.Typable). That way, you'd get 'Monad (Either a)' without Error constraint, but with strictly more defined fail ('Left _|_' instead of '_|_'), and others can add even more defined fail when needed. If you are concerned about something else, please explain how a less defined instance in Control.Monad.Instances is going to address your concern in a way a more defined instance cannot. Claus