Warn against using 'fail' directly in user-code

Stijn van Drongelen rhymoid at gmail.com
Fri Dec 20 23:14:19 UTC 2013


On Fri, Dec 20, 2013 at 6:27 PM, Ganesh Sittampalam <ganesh at earth.li> wrote:

> On 16/12/2013 16:50, Herbert Valerio Riedel wrote:
> > On 2013-12-16 at 14:54:53 +0100, Andreas Abel wrote:
> >> On 16.12.2013 14:12, Roman Cheplyaka wrote:
> >>>>> The purpose of 'fail' is to handle monadic pattern-match failures.
> >>>>> I consider explicit use of 'fail' in user code a hack.
> >>>
> >>> I treat 'fail' as a semi-private method of the Monad class. I may
> >>> override it, but I should never call it. It only exists for the
> >>> compiler.
> >>
> >> This is useful information.  Please add it to the documentation.  That
> >> would definitely help newcomers to get some orientation in the design
> >> space of exceptions...
> >
> > [...]
> >
> > If this is really the intent of `fail`, shouldn't we then also attach a
> >
> >   {-# WARNING fail "Monad(fail) is not supposed to be called directly"
> #-}
> >
> > to the `fail` method definition to help catch illegal uses of `fail` in
> > user code?
> >
> > (Fwiw, I've tested attaching such a warning to `fail` in GHC HEAD's
> > libraries/base/GHC/Base.lhs and it seems to work just fine so far... so
> > if there's consensus, we could add that for GHC 7.8)
>
> I'm not sure I follow the logic of this. If it does continue to exist,
> what are the arguments against using it explicitly?
>
> Cheers,
>
> Ganesh
>

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.)

Regards,
Stijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131221/7366e89d/attachment.html>


More information about the Libraries mailing list