Thanks for response; unfortunately my problem was a bit deeper. Note to self: try to verify all code snippets before posting ;-) The problem is that code on line 4 is useless. If one of the arguments a or b is Nothing, computation will just return Nothing and will not bother to execute lines 4-5: 1 foo a b = do 2 output "before" 3 let r = liftM2 (+) a b 4 when (r == Nothing) $ output "error" 5 return r -- ??? "lift r" I guess it does make perfect sense. It just was not intuitive to me that as soon as I use Maybe monad in my monad transformation I will loose ability to do output *after* error occurred. But, anyway, I think I was able to find a nice solution to that: type M2 a = OuptutMonadT Maybe String a whenError:: M2 a -> M2 a -> M2 a … 1 foo a b = do 2 output "before" 3 let r = liftM2 (+) a b 4 `whenError` $ reportError "error" 5 return r whenError combines two computations so that if first fails it will use second instead. Thanks, Pavel.

You are absolutely right! I missed that ‘let’. And it does work, thanks. On the other hand it is still not what I intended, so I decided not to use Monads in this particular case. I wanted to represent values that can fail and that have complete history of errors. So that if I calculate c = (liftM2 (+)) a b and if *both* a and b have failed, c would also fail plus it would have history of errors form a and b (and potentially it’s own). I tried to do this by combining Maybe and Output monads. Now I realize that as long as I am using liftM2 it is not possible to have history of errors from a and b - only form a. And as I moved to custom lift functions I realized I didn’t need monads in the first place. Anyway, thanks for your help, it is very much appreciated. Regards, Pavel. I didn’t know you can have ‘let’ without ‘in’ in do expressions, nice!

Jules Bean wrote:

However, your problem *does* have a natural underlying monad, if you care to use it.

I may be confused, but I don't think it does. It seems like the OP wants a type like data Perhaps a = Success a | Failure [Error] and semantics like liftM2 (+) (Failure [error1]) (Failure [error2]) === Failure [error1,error2] where liftM2 f a1 a2 = a1 >>= p where p v1 = a2 >>= q where q v2 = return (f v1 v2) I don't see how to define (>>=) such that this will return the appropriate value. If a1 fails you must call p in order to collect additional errors, but there's no appropriate value of v1 that you can pass. But it's easy with a custom lifting function: liftPerhaps2 f (Success x) (Success y) = Success (f x y) liftPerhaps2 f p q = Failure (errors p ++ errors q) where errors (Success _) = [] errors (Failure es) = es -- Ben

On 1 Dec 2004, at 00:37, Marcin 'Qrczak' Kowalczyk wrote:

Ben Rudiak-Gould writes:

...

I may be confused, but I don't think it does. It seems like the OP wants a type like

data Perhaps a = Success a | Failure [Error]

When writing a compiler, it makes sense to collect errors as by the writer monad, and not abort anything - producing dummy values instead (except perhaps some fatal errors when it's inconvenient).

Or you could use the monad: data Perhaps a = Success a | Failure a [Error] instance Monad Perhaps where Success a >>= k = k a Failure a es >>= k = Failure (value (k a)) (errors (k a) ++ es) where value Success b = b value Failure b _ = b errors Success _ = [] errors Failure _ fs = fs ...such that failures must also produce a value (which could be some approximating 'best guess' based on incorrect input, or some simple default value). This is just a special case of the writer monad, I think. Jules

On 30 Nov 2004, at 23:29, Ben Rudiak-Gould wrote:

Jules Bean wrote:

...

However, your problem *does* have a natural underlying monad, if you care to use it.

I may be confused, but I don't think it does. It seems like the OP wants a type like

data Perhaps a = Success a | Failure [Error]

[snip]

I don't see how to define (>>=) such that this will return the appropriate value. If a1 fails you must call p in order to collect additional errors, but there's no appropriate value of v1 that you can pass.

Yes, I see I spoke too quickly. Perhaps a = Success a | Failure [Error] is a monad, but the bind (>>=) operation doesn't do what the OP needs, since just like the bind for maybe, it will abort the computation when an error is returned. But you can define combinators in this monad which do what the OP wants (and you did one of them in your message), it's just that haskell's do notation doesn't work, since the do notation is a shorthand for >>=, and >>= is the wrong strategy for this problem. Jules