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

[Simon Marlow]

On 30/06/2010 16:44, Henning Thielemann wrote:
>
> On Wed, 30 Jun 2010, Tyson Whitehead wrote:
>
>> Perhaps it could be pushed it into it's own type class, which would then
>> required by the do notation? Exactly like mdo required MonadFix. I
>> understand there was one called MonadZero for this at some time?
>
> I assume that there is no need to change the compiler, just the library,
> or even just the imports, since GHC will simply insert 'fail' where
> necessary and this automatically introduces the type class constraints
> that 'fail' has. If a custom 'fail' from a new MonadError class is in
> scope, then MonadError will be required for the whole expression that a
> 'do' block represents.

I believe the reason that fail was moved into the Monad class was that 
having constraints pop up unpredictably just because you added a pattern 
match was ugly and inconvenient (rather like the rationale for dropping 
the Data constraint on seq, and the similar problem with implicit 
parameters).  If you add another constructor to a single-constructor 
data type, do all your pattern matches suddenly generate new 
constraints, requiring you to fix all your type signatures?

I don't know all the ins and outs of the discussion here, but before 
proposing to reverse this decision someone should do a careful 
assessment of the prior rationale and results of subsequent experience.

Cheers,
	Simon