Relax the Either monad

[Iavor Diatchki]

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 <gale at sefer.org> wrote:
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>