David Menendez wrote:
In general, monads don't compose. That is, there's no foolproof way to
take two monads m1 and m2 and create a third monad m3 which does
everything m1 and m2 does. People mostly get around that by using
monad transformers.
...OK then.
You could try using an exception monad transformer here
I thought I already was?
At least, I spent about an hour reading through Control.Monad.Error
trying to figure out what the hell is going on, and eventually arrived
at a type signature that represents what I'm trying to do and seems to
be accepted as a monad. But I can't define a working AND function with
it. :-(
I was under the impression that you can stack monad transformers on top
of each other and get it to work, but it doesn't seem to want to work
for me...
but that
won't give you the same semantics. "ErrorT ErrorType ResultSet a" is
isomorphic to "ResultSet (Either ErrorType a)".
Hmm. That would be something quite different. Either the entire
computation fails returning a reason why, or it produces a normal result
set.
If you must have something equivalent to Either ErrorType (ResultSet
a), you either need to (1) redesign ResultSet to include error
handling, (2) redesign ResultSet to be a monad transformer, or (3)
restrict yourself to the operations in Applicative.
Option (3) works because applicative functors *do* compose. (Also,
every instance of Monad is trivially an instance of Applicative.)
Uh... what's Applicative? (I had a look at Control.Applicative, but it
just tells me that it's "a strong lax monoidal functor". Which isn't
very helpful, obviously.)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
