<br><div class="gmail_quote">On Fri, Dec 7, 2012 at 12:45 PM, Ross Paterson <span dir="ltr"><<a href="mailto:ross@soi.city.ac.uk" target="_blank">ross@soi.city.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Dec 07, 2012 at 09:44:27AM +0000, Roman Cheplyaka wrote:<br>
> I propose to add the sole module of the 'either' package[1],<br>
> Control.Monad.Trans.Either, to the transformers package.<br>
><br>
> It provides EitherT, a very basic and fundamental data type. The<br>
> difference between EitherT and ErrorT is that the latter has an Error<br>
> constraint, which is used to imlement 'fail'.<br>
><br>
> Note that 'either' depends on the 'semigroupoids' and 'semigroup'<br>
> packages to provide appropriate instances. The proposal is not to add<br>
> those instances to 'transformers' to avoid additional dependencies. The<br>
> instances can then be left in the 'either' package or moved to the<br>
> 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids'<br>
> already depends on 'transformers', while 'semigroups' does not).<br>
<br>
</div>Orphan instances are to be avoided, so moving the instances to those<br>
packages seems the only option.</blockquote><div><br></div><div>Sure. I'd be happy to invert the dependencies. As I wrote semigroups, </div><div>semigroupoids and either in the first place. ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> Compared to the 'either' package, Show, Read, Eq and Ord instances will<br>
> be dropped to keep the code Haskell2010 (those instances require<br>
> FlexibleInstances, FlexibleContexts, and UndecidableInstances).<br>
<br>
</div>That's true. Some other points:<br>
<br>
The either package has mapEitherT as the binary map<br>
<br>
mapEitherT :: Functor m => (e -> f) -> (a -> b) -> EitherT e m a -> EitherT f m b<br>
<br>
but consistency with the rest of transformers would apply this name to<br>
<br>
mapEitherT :: (m (Either e a) -> n (Either e' b)) -> EitherT e m a -> EitherT e' n b<br>
mapEitherT f m = EitherT $ f (runEitherT m)<br></blockquote><div> </div><div>Something that provides the existing 'mapEitherT' functionality would be nice to retain as it gets used in multiple packages. Perhaps bikeshed it to 'bimapEitherT', and use 'mapEitherT' for your notion?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(The binary map can't be recovered using Bifunctor because of the argument<br>
order.)<br>
<br>
either has<br>
<br>
hoistEither :: Monad m => Either e a -> EitherT e m a<br>
<br>
Maybe transformers should have similar functions for all the other monad<br>
transformers.<br></blockquote><div><br></div><div>+1 I would really like this. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
left and right are used with different meanings in Control.Arrow<br>
(surmountable with qualification, of course). I see that the idea<br>
is to be symmetrical, but the monad structure is asymmetric.<br></blockquote><div><br></div><div>I'm not wedded to the names of the 'left' and 'right' combinators in 'either'. </div><div><br></div>
<div>The functionality would be nice to retain, but the names I'm completely indifferent to.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Would we want a catch function?</blockquote><div><br></div><div>It probably wouldn't hurt.</div><div> </div><div>-Edward</div></div>