Roman Cheplyaka | 7 Dec 10:44 2012

Proposal: merge either into transformers

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
Attachment (either.diff): text/x-diff, 3980 bytes
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
(Continue reading)

Michael Snoyman | 7 Dec 10:56 2012

Re: Proposal: merge either into transformers




On Fri, Dec 7, 2012 at 11:44 AM, Roman Cheplyaka <roma <at> ro-che.info> 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).

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


+1

Michael
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Herbert Valerio Riedel | 7 Dec 11:11 2012
Picon

Re: Proposal: merge either into transformers

Roman Cheplyaka <roma <at> ro-che.info> 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*'
Gregory Collins | 7 Dec 13:55 2012
Picon

Re: Proposal: merge either into transformers

On Fri, Dec 7, 2012 at 10:44 AM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
> I propose to add the sole module of the 'either' package[1],
> Control.Monad.Trans.Either, to the transformers package.

+1
--
Gregory Collins <greg <at> gregorycollins.net>
Edward Kmett | 7 Dec 17:46 2012
Picon

Re: Proposal: merge either into transformers

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 <greg <at> gregorycollins.net> wrote:
On Fri, Dec 7, 2012 at 10:44 AM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
> I propose to add the sole module of the 'either' package[1],
> Control.Monad.Trans.Either, to the transformers package.

+1
--
Gregory Collins <greg <at> gregorycollins.net>

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 8 Dec 16:15 2012
Picon

Re: Proposal: merge either into transformers

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?
Henning Thielemann | 8 Dec 23:55 2012
Picon

Re: Proposal: merge either into transformers


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?
Ross Paterson | 9 Dec 02:24 2012
Picon

Re: Proposal: merge either into transformers

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
Edward A Kmett | 9 Dec 02:38 2012
Picon

Re: Proposal: merge either into transformers

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 <ross <at> soi.city.ac.uk> 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
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Ross Paterson | 9 Dec 03:00 2012
Picon

Re: Proposal: merge either into transformers

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.
Edward Kmett | 9 Dec 03:51 2012
Picon

Re: Proposal: merge either into transformers

On Sat, Dec 8, 2012 at 9:00 PM, Ross Paterson <ross <at> soi.city.ac.uk> wrote:

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).

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.

> (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.

Indeed I do.

-Edward
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 9 Dec 18:58 2012
Picon

Re: Proposal: merge either into transformers


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.
Ross Paterson | 12 Dec 17:05 2012
Picon

Re: Proposal: merge either into transformers

On Sun, Dec 09, 2012 at 01:24:36AM +0000, 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
> 
> 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

To also lift Prelude classes like Show to Compose (which seems
desirable), we'd need to use an explicit dictionary instead:

class ShowF f where
    showsPrecF :: (Int -> a -> ShowS) -> Int -> f a -> ShowS

instance (ShowF f, ShowF g) => ShowF (Compose f g) where
    showsPrecF sp d (Compose x) = showParen (d > 10) $
        showString "Compose " . showsPrecF (showsPrecF sp) 11 x

instance (ShowF f, ShowF g, Show a) => Show (Compose f g a) where
    showsPrec = showsPrecF showsPrec
Henning Thielemann | 12 Dec 18:20 2012
Picon

Re: Proposal: merge either into transformers


On Wed, 12 Dec 2012, Ross Paterson wrote:

> On Sun, Dec 09, 2012 at 01:24:36AM +0000, 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
>>
>> 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
>
> To also lift Prelude classes like Show to Compose (which seems
> desirable), we'd need to use an explicit dictionary instead:
>
> class ShowF f where
>    showsPrecF :: (Int -> a -> ShowS) -> Int -> f a -> ShowS
>
> instance (ShowF f, ShowF g) => ShowF (Compose f g) where
>    showsPrecF sp d (Compose x) = showParen (d > 10) $
>        showString "Compose " . showsPrecF (showsPrecF sp) 11 x
>
> instance (ShowF f, ShowF g, Show a) => Show (Compose f g a) where
>    showsPrec = showsPrecF showsPrec

If you tolerate a (Functor f) constraint you may use a helper type, that 
lifts (ShowF f, Show a) to (Show (f a)):

class ShowF f where
     showsPrecF :: (Show a) => Int -> f a -> ShowS

newtype Inner g a = Inner (g a)

instance (ShowF g, Show a) => Show (Inner g a) where
     showsPrec p (Inner g) = showsPrecF p g

instance (Functor f, ShowF f, ShowF g) => ShowF (Compose f g) where
     showsPrecF d (Compose x) = showParen (d > 10) $
         showString "Compose " . showsPrecF 11 (fmap Inner x)

instance (Functor f, ShowF f, ShowF g, Show a) => Show (Compose f g a) where
     showsPrec = showsPrecF

You may also make Functor a superclass of ShowF.
Ross Paterson | 16 Dec 02:06 2012
Picon

Re: Proposal: merge either into transformers

On Wed, Dec 12, 2012 at 05:20:06PM +0000, Henning Thielemann wrote:
> On Wed, 12 Dec 2012, Ross Paterson wrote:
> 
> > On Sun, Dec 09, 2012 at 01:24:36AM +0000, 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
> >>
> >> 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
> >
> > To also lift Prelude classes like Show to Compose (which seems
> > desirable), we'd need to use an explicit dictionary instead:
> >
> > class ShowF f where
> >    showsPrecF :: (Int -> a -> ShowS) -> Int -> f a -> ShowS
> >
> > instance (ShowF f, ShowF g) => ShowF (Compose f g) where
> >    showsPrecF sp d (Compose x) = showParen (d > 10) $
> >        showString "Compose " . showsPrecF (showsPrecF sp) 11 x
> >
> > instance (ShowF f, ShowF g, Show a) => Show (Compose f g a) where
> >    showsPrec = showsPrecF showsPrec
> 
> If you tolerate a (Functor f) constraint you may use a helper type, that 
> lifts (ShowF f, Show a) to (Show (f a)):
> 
> class ShowF f where
>      showsPrecF :: (Show a) => Int -> f a -> ShowS
> 
> newtype Inner g a = Inner (g a)
> 
> instance (ShowF g, Show a) => Show (Inner g a) where
>      showsPrec p (Inner g) = showsPrecF p g
> 
> instance (Functor f, ShowF f, ShowF g) => ShowF (Compose f g) where
>      showsPrecF d (Compose x) = showParen (d > 10) $
>          showString "Compose " . showsPrecF 11 (fmap Inner x)
> 
> instance (Functor f, ShowF f, ShowF g, Show a) => Show (Compose f g a) where
>      showsPrec = showsPrecF

Doing an fmap just to make an instance work is pretty unpleasant, but
having to hand-write all the instances, as the explicit dictionary
version would require, is probably worse.

> You may also make Functor a superclass of ShowF.

I'm not sure about that -- one might want to make Set an instance.

Assuming we have Eq1, Ord1, Show1 and Read1, what would be a good name
for the module defining them?
Henning Thielemann | 16 Dec 10:40 2012
Picon

Re: Proposal: merge either into transformers


On Sun, 16 Dec 2012, Ross Paterson wrote:

> Doing an fmap just to make an instance work is pretty unpleasant, but
> having to hand-write all the instances, as the explicit dictionary
> version would require, is probably worse.
>
>> You may also make Functor a superclass of ShowF.
>
> I'm not sure about that -- one might want to make Set an instance.

Right.

> Assuming we have Eq1, Ord1, Show1 and Read1, what would be a good name
> for the module defining them?

Data.Functor.Class ?

Ok, Set is not a Functor. :-(
Ross Paterson | 7 Dec 18:45 2012
Picon

Re: Proposal: merge either into transformers

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?
Edward Kmett | 7 Dec 19:01 2012
Picon

Re: Proposal: merge either into transformers


On Fri, Dec 7, 2012 at 12:45 PM, Ross Paterson <ross <at> soi.city.ac.uk> wrote:
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.

Sure. I'd be happy to invert the dependencies. As I wrote semigroups, 
semigroupoids and either in the first place. ;)
 
> 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)
 
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
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.

+1 I would really like this. 

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.

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
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
wren ng thornton | 9 Dec 15:01 2012

Re: Proposal: merge either into transformers

On 12/7/12 1:01 PM, Edward Kmett wrote:
> On Fri, Dec 7, 2012 at 12:45 PM, Ross Paterson <ross <at> soi.city.ac.uk> 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
Simon Hengel | 7 Dec 20:03 2012
Picon

Re: Proposal: merge either into transformers

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
Dan Burton | 7 Dec 20:32 2012
Picon

Re: Proposal: merge either into transformers

+1
 
deprecate the either package, and try to find a home for those orphans.
 
-- Dan Burton
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Wiegley | 8 Dec 00:58 2012

Re: Proposal: merge either into transformers

>>>>> Roman Cheplyaka <roma <at> ro-che.info> 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
Mario Blažević | 10 Dec 17:17 2012

Re: Proposal: merge either into transformers

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.
Ross Paterson | 10 Dec 17:35 2012
Picon

Re: Proposal: merge either into transformers

On Mon, Dec 10, 2012 at 04:17:23PM +0000, Mario Blažević wrote:
> 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.

That's not the same thing:

newtype EitherT e m a = EitherT { runEitherT :: m (Either e a) }

data EitherFunctor l r x = LeftF (l x) | RightF (r x)

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Mario Blažević | 10 Dec 17:43 2012

Re: Proposal: merge either into transformers

On 12-12-10 11:35 AM, Ross Paterson wrote:
> On Mon, Dec 10, 2012 at 04:17:23PM +0000, Mario Blažević wrote:
>> 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.
>
> That's not the same thing:
>
> newtype EitherT e m a = EitherT { runEitherT :: m (Either e a) }
>
> data EitherFunctor l r x = LeftF (l x) | RightF (r x)

	I let my hopes run wild. Oh well, I'm still okay with the change. Any 
chance of having an equivalent of EitherFunctor included in Transformers 
as well?

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Edward Kmett | 10 Dec 19:57 2012
Picon

Re: Proposal: merge either into transformers

There is Data.Functor.Coproduct in comonad-transformers (http://hackage.haskell.org/packages/archive/comonad-transformers/3.0/doc/html/Data-Functor-Coproduct.html) which could be moved.


I never really liked having it in the comonad-transformers package anyways. 

-Edward

On Mon, Dec 10, 2012 at 11:43 AM, Mario Blažević <mblazevic <at> stilo.com> wrote:
On 12-12-10 11:35 AM, Ross Paterson wrote:
On Mon, Dec 10, 2012 at 04:17:23PM +0000, Mario Blažević wrote:
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.

That's not the same thing:

newtype EitherT e m a = EitherT { runEitherT :: m (Either e a) }

data EitherFunctor l r x = LeftF (l x) | RightF (r x)

        I let my hopes run wild. Oh well, I'm still okay with the change. Any chance of having an equivalent of EitherFunctor included in Transformers as well?




_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Mario Blažević | 10 Dec 22:38 2012

Re: Proposal: merge either into transformers

On 12-12-10 01:57 PM, Edward Kmett wrote:
> There is Data.Functor.Coproduct in comonad-transformers
> (http://hackage.haskell.org/packages/archive/comonad-transformers/3.0/doc/html/Data-Functor-Coproduct.html)
> which could be moved.
>
> I never really liked having it in the comonad-transformers package anyways.

	There is also Cgm.Data.Functor.Sum in cognimeta-utils, though it 
doesn't come with a Functor instance for some reason. I think I prefer 
Data.Functor.Sum to Data.Functor.Coproduct. There may be more 
occurrences in Hackage, hiding under less obious names.

	I presume this addition to Transformers would require a new proposal?
Edward Kmett | 10 Dec 22:51 2012
Picon

Re: Proposal: merge either into transformers

The problem with Data.Functor.Sum is that Data.Monoid exports Sum. While I don't think we should try to globally avoid all conflicts, I don't think we should go out of our way to pick up a conflict we don't have to have.



On Mon, Dec 10, 2012 at 4:38 PM, Mario Blažević <mblazevic <at> stilo.com> wrote:
On 12-12-10 01:57 PM, Edward Kmett wrote:
There is Data.Functor.Coproduct in comonad-transformers
(http://hackage.haskell.org/packages/archive/comonad-transformers/3.0/doc/html/Data-Functor-Coproduct.html)
which could be moved.

I never really liked having it in the comonad-transformers package anyways.

        There is also Cgm.Data.Functor.Sum in cognimeta-utils, though it doesn't come with a Functor instance for some reason. I think I prefer Data.Functor.Sum to Data.Functor.Coproduct. There may be more occurrences in Hackage, hiding under less obious names.

        I presume this addition to Transformers would require a new proposal?


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Mario Blažević | 10 Dec 23:07 2012

Re: Proposal: merge either into transformers

On 12-12-10 04:51 PM, Edward Kmett wrote:
> The problem with Data.Functor.Sum is that Data.Monoid exports Sum. While
> I don't think we should try to globally avoid all conflicts, I don't
> think we should go out of our way to pick up a conflict we don't have to
> have.

	Both Data.Monoid and Data.Functor.Product export a type named Product. 
I guess you could argue that there was no choice in case of Product, 
while Sum can be called a Coproduct.

	That being said, I don't care what the name is as long as it's 
available from the transforms package. Do you want to push the proposal?

>
> On Mon, Dec 10, 2012 at 4:38 PM, Mario Blažević <mblazevic <at> stilo.com
> <mailto:mblazevic <at> stilo.com>> wrote:
>
>     On 12-12-10 01:57 PM, Edward Kmett wrote:
>
>         There is Data.Functor.Coproduct in comonad-transformers
>         (http://hackage.haskell.org/__packages/archive/comonad-__transformers/3.0/doc/html/__Data-Functor-Coproduct.html
>         <http://hackage.haskell.org/packages/archive/comonad-transformers/3.0/doc/html/Data-Functor-Coproduct.html>)
>         which could be moved.
>
>         I never really liked having it in the comonad-transformers
>         package anyways.
>
>
>              There is also Cgm.Data.Functor.Sum in cognimeta-utils,
>     though it doesn't come with a Functor instance for some reason. I
>     think I prefer Data.Functor.Sum to Data.Functor.Coproduct. There may
>     be more occurrences in Hackage, hiding under less obious names.
>
>              I presume this addition to Transformers would require a new
>     proposal?
>
>

--

-- 
Mario Blazevic
mblazevic <at> stilo.com
Stilo International

This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient(s) please contact the sender by reply email and destroy
all copies of the original message and any attachments.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Edward Kmett | 10 Dec 23:29 2012
Picon

Re: Proposal: merge either into transformers

If you make the proposal, i'll happily +1 it ;)

On Mon, Dec 10, 2012 at 5:07 PM, Mario Blažević <mblazevic <at> stilo.com> wrote:
On 12-12-10 04:51 PM, Edward Kmett wrote:
The problem with Data.Functor.Sum is that Data.Monoid exports Sum. While
I don't think we should try to globally avoid all conflicts, I don't
think we should go out of our way to pick up a conflict we don't have to
have.

        Both Data.Monoid and Data.Functor.Product export a type named Product. I guess you could argue that there was no choice in case of Product, while Sum can be called a Coproduct.

        That being said, I don't care what the name is as long as it's available from the transforms package. Do you want to push the proposal?



On Mon, Dec 10, 2012 at 4:38 PM, Mario Blažević <mblazevic <at> stilo.com
<mailto:mblazevic <at> stilo.com>> wrote:

    On 12-12-10 01:57 PM, Edward Kmett wrote:

        There is Data.Functor.Coproduct in comonad-transformers
        (http://hackage.haskell.org/__packages/archive/comonad-__transformers/3.0/doc/html/__Data-Functor-Coproduct.html
        <http://hackage.haskell.org/packages/archive/comonad-transformers/3.0/doc/html/Data-Functor-Coproduct.html>)

        which could be moved.

        I never really liked having it in the comonad-transformers
        package anyways.


             There is also Cgm.Data.Functor.Sum in cognimeta-utils,
    though it doesn't come with a Functor instance for some reason. I
    think I prefer Data.Functor.Sum to Data.Functor.Coproduct. There may
    be more occurrences in Hackage, hiding under less obious names.

             I presume this addition to Transformers would require a new
    proposal?




--
Mario Blazevic
mblazevic <at> stilo.com
Stilo International

This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient(s) please contact the sender by reply email and destroy
all copies of the original message and any attachments.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Vincent Hanquez | 24 Apr 16:45 2014

Re: Proposal: merge either into transformers

On 2012-12-07 09:44, 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).
>
> 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).
>

[Sorry to revive this 1 yr 1/2 thread, but I was looking at the reason 
why we don't have eitherT is a more canonical place like transformers,
and ended up here ...]

Is there a reason why this thread ran out of steam ? It not totally 
obvious from the answers what was missing to move forward.
It seems like there's general agreement that EitherT is a good addition, 
did this proposal got forgotten ? Is there a way to revive this proposal ?

Cheers,
--

-- 
Vincent
Roman Cheplyaka | 24 Apr 17:14 2014

Re: Proposal: merge either into transformers

* Vincent Hanquez <tab <at> snarc.org> [2014-04-24 15:45:34+0100]
> On 2012-12-07 09:44, 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).
> >
> >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).
> >
> 
> [Sorry to revive this 1 yr 1/2 thread, but I was looking at the reason why
> we don't have eitherT is a more canonical place like transformers,
> and ended up here ...]
> 
> Is there a reason why this thread ran out of steam ? It not totally obvious
> from the answers what was missing to move forward.
> It seems like there's general agreement that EitherT is a good addition, did
> this proposal got forgotten ? Is there a way to revive this proposal ?

IIRC, last time this was brought up, Ross said that he'd take action after GHC
7.8 is released. So your reminder is well timed, in fact ;)

Roman
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Gmane