On Dec 21, 2013 11:13 AM, "Ganesh Sittampalam"
On 20/12/2013 23:14, Stijn van Drongelen wrote:
Some monads have no sensible implementation for fail, so therefore, `fail` can't be bound by any laws besides what's in the type. So when you're writing common functions involving error handling, the type of `fail` gives you some requirements on how to use it, but you get no promise that it does something useful (note: `fail = error` is not
useful).
However, when you use something like MonadError, you're guaranteed (by the type) that you can use throwError, and promised (by those who create instances for MonadError) that it will have a useful meaning.
(And this is just one of the reasons.)
But as long as it used for pattern match failures, those problems will exist anyway - is using it explicitly any worse than writing incomplete patterns in a do block?
Ganesh
You're right that fail can be used sensibly when there'd be a pattern match failure otherwise. I was going to write that people use fail for other things as well, but I just realize that the distinction between a pattern match failure and any other failure 'based on a value' is very vague. Warning about fail but allowing it implicitly is then a pretty unfounded solution. So I change my +1 into a -1. Let's split fail off of Monad instead. Thanks, Stijn