https://mail.haskell.org/pipermail/libraries/2015-January/024633.html
This has been raised before and rejected as it doesn't work.
The `Applicative` instance for `EitherT e m` does not have the same
semantics as the Applicative for `Compose m (Either e)`.
Consider
foo <*> bar
foo = EitherT $ return $ Left "nope"
bar = throw "die die die"
If you foo 'fails', yielding Left e then EitherT e m a _stops_. It doesn't
run the next action. On the other hand, `Compose m (Either e)` will run
both foo and bar, then merge the answers. This is observably different if
bar fails in a stronger way. e.g. if m itself is something like IO you can
throw an exception in bar. The EitherT e IO instance will never execute
bar, and never throw that exception.
These are different Applicatives for different types.
This issue has been repeatedly raised against transformers (at least once
by me, once by David Feuer), and Ross has patiently corrected us each time.
I figure it is my turn to pass along the received wisdom. ;)
The instance you request is only valid when 'm' has no notion of failure of
its own, or no notion of observable side-effects. It doesn't work for m =
IO. It doesn't work for m = Either f. In essence it isn't a valid instance
for a Monad _transformer_, but rather it is only a valid instance for
particular, well behaved, monads.
-Edward
On Thu, Apr 23, 2015 at 12:02 PM, Nikita Volkov
I've recently discovered a flaw in the Applicative and Alternative instances of EitherT. I've posted the following pull request to fix them:
https://github.com/ekmett/either/pull/38
The pull request contains the description of the problem.
ExceptT of "transformers" contains exactly the same flaw. However it's not hosted on GitHub, so I don't know a better place to report the issue then here.
Best regards, Nikita Volkov
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries