Warn against using 'fail' directly in user-code

[Stijn van Drongelen]

On Dec 21, 2013 11:13 AM, "Ganesh Sittampalam" <ganesh at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131221/660c0df8/attachment-0001.html>