Proposal: die to System.Exit (and/or Prelude)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: die to System.Exit (and/or Prelude)

Ivan Lazar Miljenovic
On 16 December 2013 22:15, Roman Cheplyaka <[hidden email]> wrote:
> * Herbert Valerio Riedel <[hidden email]> [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...)?

>
> Roman
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: die to System.Exit (and/or Prelude)

Roman Cheplyaka-2
* Ivan Lazar Miljenovic <[hidden email]> [2013-12-17 00:00:16+1100]
> On 16 December 2013 22:15, Roman Cheplyaka <[hidden email]> wrote:
> > * Herbert Valerio Riedel <[hidden email]> [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 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.

Roman

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: die to System.Exit (and/or Prelude)

Andreas Abel
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...

 
http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Monad.html#t:Monad

   fail :: String -> m a

   Fail with a message. This operation is not part of the mathematical
  definition of a monad, but is invoked on pattern-match failure in a do
expression.

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: die to System.Exit (and/or Prelude)

Andreas Abel
In reply to this post by Simon Hengel
On 14.12.2013 12:54, Simon Hengel wrote:
>      main :: IO ()
>      main = getContents >>= either die run . parseInput

Funny way to write a pipeline.  Its neither left-to-right, which would be

   getContents >>= (parseInput >>> either die run)

nor right-to-left:

   either die run . parseInput =<< getContents

A case for hlint.
So much for my smart-ass comments.

About "(to) die or not (to) die" I am rather agnostic.
-1 for adding it to the Prelude.

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

direction of pipelines (Was: Proposal: die to System.Exit (and/or Prelude))

Henning Thielemann

On Mon, 16 Dec 2013, Andreas Abel wrote:

> On 14.12.2013 12:54, Simon Hengel wrote:
>>      main :: IO ()
>>      main = getContents >>= either die run . parseInput
>
> Funny way to write a pipeline.  Its neither left-to-right, which would be
>
>  getContents >>= (parseInput >>> either die run)
>
> nor right-to-left:
>
>  either die run . parseInput =<< getContents
>
> A case for hlint.


http://www.haskell.org/haskellwiki/Direction_of_data_flow
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: die to System.Exit (and/or Prelude)

Malcolm Wallace-2
In reply to this post by Roman Cheplyaka-2

On 16 Dec 2013, at 13:12, Roman Cheplyaka wrote:

> * Ivan Lazar Miljenovic <[hidden email]> [2013-12-17 00:00:16+1100]
>> On 16 December 2013 22:15, Roman Cheplyaka <[hidden email]> wrote:
>>> * Herbert Valerio Riedel <[hidden email]> [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.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: die to System.Exit (and/or Prelude)

Roman Cheplyaka-2
* Malcolm Wallace <[hidden email]> [2013-12-16 14:17:49+0000]
> I see no good reason to distinguish between runtime pattern-match
> failure, and a direct user call of "fail".

One reason to distinguish them is that there's no good reason for fail
to have type String -> m a. Perhaps a better type would be
PatternFailureInfo -> m a, where PatternFailureInfo would include the
SrcLoc of where the failure happened, the pattern itself, maybe
something else.

So, it is possible to use fail in parsers, but only because it
incidentally has such a loose type. That's why it looks like a hack to
me.

Roman

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Warn against using 'fail' directly in user-code (was: Proposal: die to System.Exit (and/or Prelude))

Herbert Valerio Riedel
In reply to this post by Andreas Abel
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)

Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Warn against using 'fail' directly in user-code

Niklas Hambüchen
> (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)

That sounds great!

And as far as I remember, we will have MonadFail, as Malcolm mentioned,
soon.

On 16/12/13 13:54, Andreas Abel wrote
>   fail :: String -> m a
>
>   Fail with a message. This operation is not part of the mathematical
>  definition of a monad, but is invoked on pattern-match failure in a do
> expression.

This seems to go well with your change.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: die to System.Exit (and/or Prelude)

Edward Kmett-2
In reply to this post by Malcolm Wallace-2
At ICFP, Simon mentioned a willingness to revisit the placement of fail in Monad for GHC, offering to defer to the core libraries committee on the issue.

I'm somewhat loathe to do anything about this for 7.10, as I'd like to focus on changes that can be made without requiring #ifdef's in user code for the next major release, and just focus on making progress on things that are near universally accepted to be good ideas, and which can be "defended against" without CPP. e.g. finally bringing in Applicative as a superclass of Monad.

That said, for say, 7.12 a well-reasoned proposal for what to do with fail would have a very high likelihood of getting through! (for example, exiling it to a MonadFail class or to the existing MonadPlus) Especially as if the split-base proposal goes through for 7.12 a lot of breaking changes would already be in the air.

-Edward


On Mon, Dec 16, 2013 at 9:17 AM, Malcolm Wallace <[hidden email]> wrote:

On 16 Dec 2013, at 13:12, Roman Cheplyaka wrote:

> * Ivan Lazar Miljenovic <[hidden email]> [2013-12-17 00:00:16+1100]
>> On 16 December 2013 22:15, Roman Cheplyaka <[hidden email]> wrote:
>>> * Herbert Valerio Riedel <[hidden email]> [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.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Warn against using 'fail' directly in user-code

Andreas Abel
In reply to this post by Niklas Hambüchen
On 16.12.2013 18:37, Niklas Hambüchen wrote:

>> (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)
>
> That sounds great!
>
> And as far as I remember, we will have MonadFail, as Malcolm mentioned,
> soon.
>
> On 16/12/13 13:54, Andreas Abel wrote
>>    fail :: String -> m a
>>
>>    Fail with a message. This operation is not part of the mathematical
>>   definition of a monad, but is invoked on pattern-match failure in a do
>> expression.
>
> This seems to go well with your change.

Above I was just quoting the current documentation.  It should be
formulated sharper, to say explicitly "do not use `fail' to throw your
own errors!"



--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Warn against using 'fail' directly in user-code (was: Proposal: die to System.Exit (and/or Prelude))

Stijn van Drongelen
In reply to this post by Herbert Valerio Riedel



On Mon, Dec 16, 2013 at 5:50 PM, Herbert Valerio Riedel <[hidden email]> 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)

Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

+1!

I think `fail` is a huge wart anyway.

I'm still partial to the Haskell 1.4 solution to this problem, where the translation of refutable patterns in do-notation would involve `mzero` rather than `fail "Here, have some debugging info."`.

:),
Stijn

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: die to System.Exit (and/or Prelude)

Akio Takano
In reply to this post by Herbert Valerio Riedel
Hi,

On Mon, Dec 16, 2013 at 6:53 PM, Herbert Valerio Riedel <[hidden email]> wrote:

Why not simply use the existing `fail :: String -> IO a` method instead?

The differences & similiarities I see wrt `fail`:

 - `die` throws an `ExitCode` exception, whereas `fail` throws an
   `IOError` exception

 - Both result in the message written to stderr and a non-zero exit code

One problem with 'fail' is that the error message is surrounded by "user error (" and ")". This is ok for debugging, but it can be confusing for the end user.

Add System.Exit.die:            +1
Re-export it from Prelude:      +0

Takano Akio

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Warn against using 'fail' directly in user-code

Ganesh Sittampalam
In reply to this post by Herbert Valerio Riedel
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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Warn against using 'fail' directly in user-code

Stijn van Drongelen
On Fri, Dec 20, 2013 at 6:27 PM, Ganesh Sittampalam <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Warn against using 'fail' directly in user-code

Edward Kmett-2
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 <[hidden email]> wrote:
On Fri, Dec 20, 2013 at 6:27 PM, Ganesh Sittampalam <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Warn against using 'fail' directly in user-code

Jason Dagit-3



On Fri, Dec 20, 2013 at 4:58 PM, Edward Kmett <[hidden email]> wrote:
I'm personally -1 on making explicit calls to fail into a warning.

I think it really depends on how the warning is enabled. I don't think it should be part of -Wall, but I could see it being there for people that want such things. And if you're going that route, shouldn't it be part of hlint instead of ghc?

So, I think I just convinced myself that I'm -1 on this too :)

Jason

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Warn against using 'fail' directly in user-code

Ganesh Sittampalam
In reply to this post by Stijn van Drongelen
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


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Warn against using 'fail' directly in user-code

Stijn van Drongelen

On Dec 21, 2013 11:13 AM, "Ganesh Sittampalam" <[hidden email]> 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


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12