The IO case is easy and should definitely go in. That one is a no-brainer.
However, looking at it, I'm rather uncomfortable about the notion of moving the rather ad hoc Error class into base. Nobody likes it.
Perhaps the fate of the Either instance should go back out to the libraries mailing list to try to round up ideas.
We could
a.) Leave it where it is
b.) Bring Error into base.
c.) Switch it to Monoid, which is sadly too big and may break some usecases where noMsg /= mempty holds now.
d.) Bring Default into base, which IIRC was already rejected by the libraries@ list, and use that instead.
e.) Figure out something else.
We should at least split this up into the easy and the hard cases and bite off the IO instances for now, and we can explicitly punt on the Either e case until someone comes up with a better idea.
Herbert Valerio Riedelchanged title from Add MonadPlus {-{IO,Either e}-} and Alternative (Either e) instances to Add MonadPlus {+(Either e)+} and Alternative (Either e) instances
changed title from Add MonadPlus {-{IO,Either e}-} and Alternative (Either e) instances to Add MonadPlus {+(Either e)+} and Alternative (Either e) instances
These instances have been removed as of transformers-0.6, since the module where they were defined have been long deprecated and have now been removed.