[Haskell-cafe] ErrorT vs Either

Daniel Fischer daniel.is.fischer at googlemail.com
Tue May 17 00:07:28 CEST 2011

On Monday 16 May 2011 23:41:44, Gracjan Polak wrote:
> Thanks Daniel, Yves and Edward for explanation. Two things come to my
> mind now.
> 1. It should be unified.

The (Either e) Monad instance was recently changed after people have long 
complained that there shouldn't be an (Error e) constraint.
It's unlikely that that will be reverted soon.

> Why? Because conceptually:
> runIdentity (runErrorT (fail "msg")) :: Either String Int
> Left "msg"
> and
> fail "msg" :: Either String Int
> *** Exception: msg
> Should be the same as Identity monad should not add structure.

It's the (Error e) Monad which adds the structure [nowadays, Error e = 
ErrorT e Identity].

> 2. I need a Failure monad that works well with pattern match failures
> (that call fail). I'd like to use it like this:
>     runErrorT $ do
>          Active <- getStatus                -- ensure proper status
>          Just elm <- lookup stuff there     -- lookup element
>          when (condition) $ fail "wrong!"   -- check condition
>          return 1234                        -- return useful value
> sort of...

That does work, doesn't it?

> Any ideas what could be used in place of Either monad?
> Basically I need working pattern match failures (I guess that means I
> need working fail method that is not equal to error).

Roll your own,

data Result err a
    = Failure err
    | Success a
      deriving (stuff)

instance (Error err) => Monad (Result err) where ...

if ErrorT is too unwieldy. If you don't need the fail message, Maybe would 

More information about the Haskell-Cafe mailing list