Proposal: merge either into transformers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Proposal: merge either into transformers

Roman Cheplyaka-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Michael Snoyman



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],
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


+1

Michael

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Herbert Valerio Riedel
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Gregory Collins-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Edward Kmett-2
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:
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


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Ross Paterson
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Edward Kmett-2

On Fri, Dec 7, 2012 at 12:45 PM, Ross Paterson <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Simon Hengel
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Dan Burton
+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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

John Wiegley-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Gabriel Gonzalez
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Henning Thielemann-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Henning Thielemann
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Ross Paterson
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Edward Kmett-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Ross Paterson
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Edward Kmett-2
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
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

wren ng thornton
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Henning Thielemann
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
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: merge either into transformers

Mario Blažević
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
1234