[Haskell-cafe] ErrorT vs Either

[Gracjan Polak]

Daniel Fischer <daniel.is.fischer <at> googlemail.com> writes:

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

I did not request a revert, I asked about consistent behavior.
 
> It's the (Error e) Monad which adds the structure [nowadays, Error e = 
> ErrorT e Identity].

I do not understand this part. Can you elaborate?

> 
> > 
> > 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?

Indeed this does work, but it is fragile wrt refactorings.

Suppose we have the code:

  result <- runErrorT $ do
     lift $ print "was here"
     fail "msg"

  (result = Left "msg")

after a while the print statement may be removed:

  result <- runErrorT $ do
     fail "msg"

  (result = Left "msg")

and then somebody will see that inner 'do' does not depend on outer
monad so next refactoring will be:

  let result = do
     fail "msg"

  (result = error "msg")

And here code breaks...

> 
> Roll your own,

That is a good idea. I looked also at Attempt.

Thanks for responses.

-- 
Gracjan