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