Ross Paterson wrote:
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 Yay! Claus Reinke wrote:
-1, because the default definition of fail is error, which would render the Monad instance useless (unless I'm missing something?).
It would certainly not render it useless. When using Either as an error monad, the usual way to throw an error is with throwError if you are using the MonadError class, or with Left if not. At least on the surface, "fail" has nothing to do with the concept of failure that Control.Monad.Error is modeling. Instead, it is referring to "failure of a pattern match in the do-block variable binding syntax" (and its extension to list comprehensions). In my opinion, relying on a failed pattern match to result in a Left value when using the Either monad for error processing is poor programming technique. As is using the "pattern match failure" function directly in place of throwError or Left. There are plenty of better and safer ways to achieve polymorphism. However, some may disagree, so that would be a downside to this proposal. Even so, I am still strongly in favor, for the reasons well-explained by Edward. Another downside is that there may be some code out there that does use the "pattern match failure" function in this way (erroneously in my opinion). I am still strongly in favor. However, it would be a good idea to search Hackage to get an idea of the scope of the breakage ahead of time, so that we can prepare for it. Regards, Yitz