-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.
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.
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.
I am not talking about Control.Monad.Error failure, I am talking about things that can happen in a monadic computation, and increasingly refined data types that allow us to capture more and more of that (Id, Maybe, Either a, [], as in the old Monad papers). Whether we then structure the processing of the captured information according to MonadError or MonadPlus or something else, is a different story. However, it is my experience that the most useful definitions of fail for my purposes were those that corresponded to mzero.
Instead, it is referring to "failure of a pattern match in the do-block variable binding syntax" [..] 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.
Why? Unless you choose to throw away the information (resorting to exceptions where simple data structure suffices), Left is the obvious candidate (since Right is taken for return).
As is using the "pattern match failure" function directly in place of throwError or Left.
How do you want to capture pattern match failure in an 'Either a' Monad if fail is defined as error?
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.
Moving a 'Monad (Either a)' instance is going to break things outside hackage, too (I think I first encountered this issue when combining Strafunski and Programatica for use in HaRe). It is also going to unbreak some things (where two packages defined equivalent instances), which is the point of the proposal, but will cause version bumps and incompatibilities. So this is going to be a breaking change, not something one would want to get wrong or have to redo. Hackage stats would be useful, also a "heads up" warning on haskell-cafe. The only way to fix rather than move the orphan instance issue here would be for mtl and the like to use their own Either-variants. Instead, this proposal appears to be about fixing a single 'Monad (Either a)' instance in base. Which might be good, but that instance should better be right for everyone. Claus