Hello,
Note: this is shamless plug :-)
I agree with pretty much all you say, except that I tend to think of
the error monad as an abstract type, and not assume that it is the
Either type. This is how things are done in the monad library I
implemented (www.cse.ogi.edu/~diatchki/monadLib). In principle it is
very similar to the library distributed with GHC, so it should be easy
to pick up.
-Iavor
On Sun, 20 Mar 2005 17:03:52 +0200, Yitzchak Gale
An instance of Monad (Either a) is defined in Control.Monad.Error. Unfortunately, that instance requires the type "a" to be an instance of Error.
In fact, using Either for exception handling is only a special case. The Either monad is more generally useful for any complex calculation that needs to exit in the middle and return a value, including multi-level exit.
(And no thank you, I would not like to obfuscate my code by using Cont and callCC for that. The Either monad is simple and clean.)
It is annoying to work around this problem, since one often has to import Control.Monad.Error. Could this restriction be removed?
The Error instance is not used, except to define fail. I don't think it is really important to have a Monad instance where fail references the Error instance; throwError is much more clear.
But if others disagree, perhaps a synonym could be used for Either in the context of exceptions. Anyway the namespace there is a bit of a mess; one expects Error to be the non-transforming version of ErrorT, but it is not. How about Throws or Thrown, so I can say:
myFun :: a -> b -> c -> Error1 `Thrown` Error2 `Thrown` Error3 `Thrown` ReturnType
-Yitz _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries