Proposal: die to System.Exit (and/or Prelude)
Malcolm Wallace
malcolm.wallace at me.com
Mon Dec 16 14:17:49 UTC 2013
On 16 Dec 2013, at 13:12, Roman Cheplyaka wrote:
> * Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> [2013-12-17 00:00:16+1100]
>> On 16 December 2013 22:15, Roman Cheplyaka <roma at ro-che.info> wrote:
>>> * Herbert Valerio Riedel <hvr at gnu.org> [2013-12-16 10:53:21+0100]
>>>> Why not simply use the existing `fail :: String -> IO a` method instead?
>>>
>>> The purpose of 'fail' is to handle monadic pattern-match failures.
>>> I consider explicit use of 'fail' in user code a hack.
>>
>> Or for use with parser-combinator libraries (though I suppose this
>> could be seen as a pattern-match failure...)?
>
> I'd consider that an abuse, too. E.g. Parsec provides a parserFail
> function that you can call instead.
I respectfully disagree. Whilst it was probably a mistake originally to include "fail" as a method of the Monad class, it has always been a useful additional method. Personally, I would have it in a separate class (called MonadFail, or similar). But wherever it lives, we would always have had it.
I see no good reason to distinguish between runtime pattern-match failure, and a direct user call of "fail". It is quite common to write parsers using pattern-matching, and why should one kind of backtracking be privileged over another? Their effects are of exactly the same kind.
e.g.
keyword = ( do "let" <- word -- fails if the string does not match
b <- binding
return (LET b) )
`onFail`
( do "case" <- word
exp <- expression
"of" <- word `onFail` fail "missing keyword 'of'"
alts <- many1 alternative
return (CASE exp alts) )
etc.
More information about the Libraries
mailing list