I propose to add the sole module of the 'either' package[1],
Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries either.diff (4K) Download Attachment |
On Fri, Dec 7, 2012 at 11:44 AM, Roman Cheplyaka <[hidden email]> wrote: I propose to add the sole module of the 'either' package[1], +1 Michael _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Roman Cheplyaka-2
Roman Cheplyaka <[hidden email]> writes:
> I propose to add the sole module of the 'either' package[1], > Control.Monad.Trans.Either, to the transformers package. +1 [...] > Note that 'either' depends on the 'semigroupoids' and 'semigroup' btw, the package is named 'semigroup*s*' _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Roman Cheplyaka-2
On Fri, Dec 7, 2012 at 10:44 AM, Roman Cheplyaka <[hidden email]> wrote:
> I propose to add the sole module of the 'either' package[1], > Control.Monad.Trans.Either, to the transformers package. +1 -- Gregory Collins <[hidden email]> _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
I will be sad to see those instances go, but I'm also +1
On Fri, Dec 7, 2012 at 7:55 AM, Gregory Collins <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Roman Cheplyaka-2
On Fri, Dec 07, 2012 at 09:44:27AM +0000, Roman Cheplyaka wrote:
> I propose to add the sole module of the 'either' package[1], > Control.Monad.Trans.Either, to the transformers package. > > It provides EitherT, a very basic and fundamental data type. The > difference between EitherT and ErrorT is that the latter has an Error > constraint, which is used to imlement 'fail'. > > Note that 'either' depends on the 'semigroupoids' and 'semigroup' > packages to provide appropriate instances. The proposal is not to add > those instances to 'transformers' to avoid additional dependencies. The > instances can then be left in the 'either' package or moved to the > 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' > already depends on 'transformers', while 'semigroups' does not). Orphan instances are to be avoided, so moving the instances to those packages seems the only option. > Compared to the 'either' package, Show, Read, Eq and Ord instances will > be dropped to keep the code Haskell2010 (those instances require > FlexibleInstances, FlexibleContexts, and UndecidableInstances). That's true. Some other points: The either package has mapEitherT as the binary map mapEitherT :: Functor m => (e -> f) -> (a -> b) -> EitherT e m a -> EitherT f m b but consistency with the rest of transformers would apply this name to mapEitherT :: (m (Either e a) -> n (Either e' b)) -> EitherT e m a -> EitherT e' n b mapEitherT f m = EitherT $ f (runEitherT m) (The binary map can't be recovered using Bifunctor because of the argument order.) either has hoistEither :: Monad m => Either e a -> EitherT e m a Maybe transformers should have similar functions for all the other monad transformers. left and right are used with different meanings in Control.Arrow (surmountable with qualification, of course). I see that the idea is to be symmetrical, but the monad structure is asymmetric. Would we want a catch function? _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
On Fri, Dec 7, 2012 at 12:45 PM, Ross Paterson <[hidden email]> wrote:
Sure. I'd be happy to invert the dependencies. As I wrote semigroups, semigroupoids and either in the first place. ;)
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?
(The binary map can't be recovered using Bifunctor because of the argument +1 I would really like this. left and right are used with different meanings in Control.Arrow I'm not wedded to the names of the 'left' and 'right' combinators in 'either'. The functionality would be nice to retain, but the names I'm completely indifferent to. Would we want a catch function? It probably wouldn't hurt. -Edward _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Roman Cheplyaka-2
On Fri, Dec 07, 2012 at 11:44:27AM +0200, Roman Cheplyaka wrote:
> I propose to add the sole module of the 'either' package[1], > Control.Monad.Trans.Either, to the transformers package. +1 _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
+1
deprecate the either package, and try to find a home for those orphans.
-- Dan Burton
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Roman Cheplyaka-2
>>>>> Roman Cheplyaka <[hidden email]> writes:
> I propose to add the sole module of the 'either' package[1], > Control.Monad.Trans.Either, to the transformers package. +1 -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Roman Cheplyaka-2
If you add a 'catch' function to `either`, I recommend using the
implementation of 'catchT' in the 'errors' package that lets you change the type of the left value so that it is symmetric to (>>=). _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
Am 07.12.2012 17:46, schrieb Edward Kmett:
> I will be sad to see those instances go, but I'm also +1 Can they be implemented in a Haskell98 manner? _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
On Fri, 7 Dec 2012, Edward Kmett wrote: > I will be sad to see those instances go, but I'm also +1 How about: import Prelude hiding (Show, showsPrec) import qualified Prelude as P class Show m where showsPrec :: (P.Show e, P.Show a) => Int -> m (Either e a) -> ShowS instance (Show m, P.Show e, P.Show a) => P.Show (EitherT e m a) where showsPrec d (EitherT m) = showParen (d > 10) $ showString "EitherT " . showsPrec 11 m and so on for Read, Eq, Ord? _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
On Sat, Dec 08, 2012 at 10:55:45PM +0000, Henning Thielemann wrote:
> > On Fri, 7 Dec 2012, Edward Kmett wrote: > > > I will be sad to see those instances go, but I'm also +1 > > How about: > > import Prelude hiding (Show, showsPrec) > import qualified Prelude as P > > class Show m where > showsPrec :: (P.Show e, P.Show a) => Int -> m (Either e a) -> ShowS > > instance (Show m, P.Show e, P.Show a) => P.Show (EitherT e m a) where > showsPrec d (EitherT m) = showParen (d > 10) $ > showString "EitherT " . showsPrec 11 m A more economical variation on this idea would be to lift these classes to functors, e.g. class ShowF f where showsPrecF :: Show a => Int -> f a -> ShowS instance (ShowF m, Show e, Show a) => Show (EitherT e m a) where showsPrec d (EitherT m) = showParen (d > 10) $ showString "EitherT " . showsPrecF 11 m instance (ShowF m, Show e) => ShowF (EitherT e m) where showsPrecF = showsPrec _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
I have a prelude-extras package that I use for 'bound' which contains those Eq1, Show1, etc classes.
(As an unrelated aside bound packages up the generalized de Bruijn indices you did with Hinze as a reusable Haskell 98 monad transformer, you may find it interesting.) Sent from my iPhone On Dec 8, 2012, at 8:24 PM, Ross Paterson <[hidden email]> wrote: > On Sat, Dec 08, 2012 at 10:55:45PM +0000, Henning Thielemann wrote: >> >> On Fri, 7 Dec 2012, Edward Kmett wrote: >> >>> I will be sad to see those instances go, but I'm also +1 >> >> How about: >> >> import Prelude hiding (Show, showsPrec) >> import qualified Prelude as P >> >> class Show m where >> showsPrec :: (P.Show e, P.Show a) => Int -> m (Either e a) -> ShowS >> >> instance (Show m, P.Show e, P.Show a) => P.Show (EitherT e m a) where >> showsPrec d (EitherT m) = showParen (d > 10) $ >> showString "EitherT " . showsPrec 11 m > > A more economical variation on this idea would be to lift these classes > to functors, e.g. > > class ShowF f where > showsPrecF :: Show a => Int -> f a -> ShowS > > instance (ShowF m, Show e, Show a) => Show (EitherT e m a) where > showsPrec d (EitherT m) = showParen (d > 10) $ > showString "EitherT " . showsPrecF 11 m > > instance (ShowF m, Show e) => ShowF (EitherT e m) where > showsPrecF = showsPrec > > _______________________________________________ > Libraries mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
On Sun, Dec 09, 2012 at 01:38:59AM +0000, Edward A Kmett wrote:
> I have a prelude-extras package that I use for 'bound' which contains those Eq1, Show1, etc classes. OK, then if me move Eq1, Ord1, Show1 and Read1 into transformers with a bunch of instances we can keep these instances for EitherT (and define some more). > (As an unrelated aside bound packages up the generalized de Bruijn indices you did with Hinze as a reusable Haskell 98 monad transformer, you may find it interesting.) You mean Richard Bird, of course. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
On Sat, Dec 8, 2012 at 9:00 PM, Ross Paterson <[hidden email]> wrote:
OK, then if me move Eq1, Ord1, Show1 and Read1 into transformers with I would definitely be +1 on the move. It would get a lot more instances than having them rotting off in a side-package of mine somewhere. I could probably then retire the package as I don't use the '2' variants very often.
Indeed I do. -Edward _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
On 12/7/12 1:01 PM, Edward Kmett wrote:
> On Fri, Dec 7, 2012 at 12:45 PM, Ross Paterson <[hidden email]> wrote: >> The either package has mapEitherT as the binary map >> >> mapEitherT :: Functor m => (e -> f) -> (a -> b) -> EitherT e m a -> >> EitherT f m b >> >> but consistency with the rest of transformers would apply this name to >> >> mapEitherT :: (m (Either e a) -> n (Either e' b)) -> EitherT e m a -> >> EitherT e' n b >> mapEitherT f m = EitherT $ f (runEitherT m) > > 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? +1 for bimapEitherT -- Live well, ~wren _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Ross Paterson
On Sun, 9 Dec 2012, Ross Paterson wrote: > A more economical variation on this idea would be to lift these classes > to functors, e.g. > > class ShowF f where > showsPrecF :: Show a => Int -> f a -> ShowS Yes, that's much better. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Roman Cheplyaka-2
On 12-12-07 04:44 AM, Roman Cheplyaka wrote:
> I propose to add the sole module of the 'either' package[1], > Control.Monad.Trans.Either, to the transformers package. +1. Then I can drop the EitherFunctor type from the monad-coroutine package. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Free forum by Nabble | Edit this page |