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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
