Warn against using 'fail' directly in user-code

[Edward Kmett]

I'm personally -1 on making explicit calls to fail into a warning.

That said I'd be more than happy to consider where we should put it if we
wanted to move it to another class on a sufficiently long time horizon to
moderate the community impact of that change.

-Edward


On Fri, Dec 20, 2013 at 6:14 PM, Stijn van Drongelen <rhymoid at gmail.com>wrote:

> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131220/9dbe9615/attachment.html>