[GHC] #974: Add partitionEithers, lefts, rights to Data.Either
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
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