#4159: move Monad and MonadFix instances for Either from mtl to base

[Claus Reinke]

>> -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