[Haskell-cafe] error vs. MonadError vs. fail

[Daniel McAllansmith]

Is there a consensus on how anticipatable failure situations should be 
handled?


There was a thread, "haskell programming guidelines", from 2006-02-25 where 
John Meacham and Cale Gibbard had a bit of back-and-forth about using 
Monad.fail or a purpose specific MonadFail class.

I believe a consensus was reached that using error should only be for 
'impossible' situations and signaling buggy code.
[Apologies if I've put words in anyones mouth.]


Using fail certainly seems quick and easy, but I find it a bit distasteful for 
a few different reasons:
 users of a library can't discriminate between a failure indicating they've 
supplied bad input and a failure indicating that teh library writer has got a 
bad pattern match somewhere,
 it doesn't seem to force the potential for failure to be explicit in the api 
of a library,
 it doesn't seem to allow distinct, and rich, failure constructs at system 
layer boundaries, or the containment of them.

Maybe the last two aren't a problem when programming in Haskell, but by itself 
the first seems pretty nasty.


Apparently the advantage of fail is that user of the library can choose to 
receive failures as eg Maybes, Eithers, [], or whatever they like.

But surely a MonadFail could allow the best of both worlds, letting the 
library throw as detailed an error construct as it can, and letting the 
library user choose MonadFail instance such that error constructs are turned 
into Maybes, Eithers, a new construct appropriate for a higher system layer, 
etc?


MonadError is not up to this task as far as I can tell.  Has anybody whipped 
up an alternative, or can explain why it can't be done?


Cheers
Daniel