You may want to take a look at anoother option in Hackage, the control-monad-exception package.

http://pepeiborra.github.com/control-monad-exception/

The control-monad-exception library provides the building blocks for

 * Explicitly Typed exceptions (checked or not)
 * which are composable
 * and even provide stack traces (experimental feature)

On 19/10/2009, at 01:00, Michael Snoyman wrote:

(Sorry, accidently took off cafe.)

On Mon, Oct 19, 2009 at 12:44 AM, Henning Thielemann <lemming@henning-thielemann.de> wrote:

On Mon, 19 Oct 2009, Michael Snoyman wrote:

Does the explicit-exception package provide what you need?

http://hackage.haskell.org/package/explicit-exception


I don't think so, but correct me if I'm wrong. I want to make it easy to chain together
computations which could fail in different ways. For example, something like this:

attemptReadInt :: String -> Attempt Int
attemptLookup :: String -> [(String, String)] -> Attempt String
attemptLookupInt :: String -> [(String, String)] -> Attempt Int
attemptLookupInt k m = attemptLookup k m >>= attemptReadInt

Now, in the explicit-exception package, I could- in this simple example- define
something like:

data MyErrors = KeyNotFound | InvalidInt


type Attempt = Exceptional MyErrors

True; that's what I meant by I could do this in my simple example.


But this solution would not scale.

You want to add other exceptions? The idea of my package is to make exceptions explicit in the type. Otherwise you would use extensible-exceptions. Or you could define MyErrors using an existential type.

Which is my point. I'm trying to provide a package for non-explicit exceptions. To compare to other programming languages, I think your package is providing the equivalent of Java checked exceptions, while mine is providing (safe) unchecked exceptions. I say safe because you still need to explicitly decide to turn an Attempt into a possible runtime exception which will bring down your program.

Defining MyErrors using an existential type would essentially recreate the entire attempt package; I don't see that purpose in everyone wanted unchecked exceptions needing to reinvent the wheel in non-compatible ways. If multiple libraries use attempt, they can easily have their possible-error-returning functions chain together safely.

I believe that control-monad-exception solves this tension between composability and explicit exceptions.
You can have explicit exceptions which are composable:

 > data DivideByZero = DivideByZero deriving (Show, Typeable)
 > data SumOverflow  = SumOverflow  deriving (Show, Typeable)

 > instance Exception DivideByZero
 > instance Exception SumOverflow

 > data Expr = Add Expr Expr | Div Expr Expr | Val Double

 > eval (Val x)     = return x
 > eval (Add a1 a2) = do
 >    v1 <- eval a1
 >    v2 <- eval a2
 >    let sum = v1 + v2
 >    if sum < v1 || sum < v2 then throw SumOverflow else return sum
 > eval (Div a1 a2) = do
 >    v1 <- eval a1
 >    v2 <- eval a2
 >    if v2 == 0 then throw DivideByZero else return (v1 / v2)

 GHCi infers the following types

 > :t eval
 >   eval :: (Throws DivideByZero l, Throws SumOverflow l) => Expr -> EM l Double

 > :t eval `catch` \ (e::DivideByZero) -> return (-1)
 >  .... :: Throws SumOverflow l => Expr -> EM l Double

 > :t runEM(eval `catch` \ (e::SomeException) -> return (-1))
 >  .... : Expr -> Double

Additionally, there's two immediate features I think I would miss from my package:

1) fail works properly, so an Attempt would be a valid monad response from people who
use that function.

As far as I understand, 'fail' is used/abused for reporting failed pattern matches in do notation. If a failed pattern match indicates a programming error, it should be a really error, and not something that must be handled at run-time.

That's a lot of very debateable statements you just made. It might be that it's strongly encouraged to only use fail for failed pattern matching, but in practice you could use it for any monadic failure. Also, there's nothing stopping a user from re-throwing pattern match exceptions received in an Attempt.

I am with Henning on 'fail'.
It must not be used as a replacement for throw, only for failed pattern matches which are programming errors and thus unchecked exceptions.