On Dec 21, 2013 11:13 AM, "Ganesh Sittampalam" <ganesh@earth.li> wrote:
>
> 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