[GHC] #974: Add partitionEithers, lefts, rights to Data.Either

Henning Thielemann lemming at henning-thielemann.de
Mon Nov 6 06:25:32 EST 2006

On Fri, 3 Nov 2006 roconnor at theorem.ca wrote:

> On Wed, 1 Nov 2006, Henning Thielemann wrote:
> > On Wed, 1 Nov 2006 roconnor at theorem.ca wrote:
> > 
> > > I've removed the controvertial isLeft, fromLeft, isRight, fromRight
> > > from the trac, and added lefts and rights. The controvertial
> > > additions can be put in a new trac. Let us focus on the the
> > > noncontrovertial additions first.
> > > 
> > > I've also renamed splitEithers into unzipEithers, which I think is better.
> > 
> > What was the reason against 'partitionEither' ? 'unzip' suggests there is
> > also a 'zip'.
> I have attached a new patch to the trac that now uses the identifier
> partitionEithers.

Sorry for being so inconstant. The more I thought about it, I found that
unzipEither is the better choice. Since 'partition' takes a function, 
which decides, where an element should go, 'partitionEither' should also 
get such an argument:
   partitionEither :: (a -> Either b c) -> [a] -> ([b], [c])
   partitionEither f = unzipEither . map f

   unzipEither :: [Either b c] -> ([b], [c])

I can imagine a 'zipEither'
   zipEither :: [Bool] -> [b] -> [c] -> [Either b c]
   zipEither = zipWith3 (\l r -> bool (Left l) (Right r))
 with the recently proposed if-then-else replacement 'bool'
 but maybe it is too simple, in order to be added to Data.Either.

Analogously I suggest
   partitionMaybe  :: (a -> Maybe b) -> [a] -> ([a], [b])
   partitionMaybe  :: (a -> Maybe b) -> [a] -> ([b], [a])
     where the parameter order of the second function is closer to
'partition' and is suitable for use in the State monad.

A similar naming question arose with respect to Data.Map functions

More information about the Libraries mailing list