Re: [Haskell-cafe] ErrorT vs Either

16 May 2011

      Daniel Fischer  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