library submission: Data.Either.unzipEithers :: [Either a b] -> ([a], [b])

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

library submission: Data.Either.unzipEithers :: [Either a b] -> ([a], [b])

Jeremy Shaw
http://hackage.haskell.org/trac/ghc/ticket/1695

This function is like unzip for a list of Eithers instead of tuples.

According to google code search, I am at least the 5th person to
implement this function:

http://www.google.com/codesearch?hl=en&lr=&q=%22%5BEither+a+b%5D+-%3E+%28%5Ba%5D%2C%5Bb%5D%29%22&btnG=Search

I opted for the name unzipEithers because the function is similar to
two existing functions: unzip and catMaybes. It seems less similar to
partition, because partition does not desconstruct the values, it just
divides them into to two groups. I have no particular attachment to
the name however.

I modeled the implementation after unzip and partition. Hopefully I
made effective use of the irrefutable patterns and laziness, but
someone else should verify.

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

Re: library submission: Data.Either.unzipEithers :: [Either a b] -> ([a], [b])

Jeremy Shaw
Oops, just realized this is a dup:

http://hackage.haskell.org/trac/ghc/ticket/974

But, perhaps we can make some progress ?
j.

At Fri, 14 Sep 2007 13:12:41 -0700,
Jeremy Shaw wrote:

>
> http://hackage.haskell.org/trac/ghc/ticket/1695
>
> This function is like unzip for a list of Eithers instead of tuples.
>
> According to google code search, I am at least the 5th person to
> implement this function:
>
> http://www.google.com/codesearch?hl=en&lr=&q=%22%5BEither+a+b%5D+-%3E+%28%5Ba%5D%2C%5Bb%5D%29%22&btnG=Search
>
> I opted for the name unzipEithers because the function is similar to
> two existing functions: unzip and catMaybes. It seems less similar to
> partition, because partition does not desconstruct the values, it just
> divides them into to two groups. I have no particular attachment to
> the name however.
>
> I modeled the implementation after unzip and partition. Hopefully I
> made effective use of the irrefutable patterns and laziness, but
> someone else should verify.
>
> j.
> _______________________________________________
> 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: library submission: Data.Either.unzipEithers :: [Either a b] -> ([a], [b])

Ian Lynagh
In reply to this post by Jeremy Shaw
On Fri, Sep 14, 2007 at 01:12:41PM -0700, Jeremy Shaw wrote:
> http://hackage.haskell.org/trac/ghc/ticket/1695

You haven't suggested a deadline. As the GHC release and ICFP et al are
coming up, how about 15 October to give people a chance to comment?

> This function is like unzip for a list of Eithers instead of tuples.

Seems fine to me.


Thanks
Ian

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

Re: library submission: Data.Either.unzipEithers :: [Either a b] -> ([a], [b])

Conor McBride
Folks

On 17 Sep 2007, at 12:57, Ian Lynagh wrote:

> On Fri, Sep 14, 2007 at 01:12:41PM -0700, Jeremy Shaw wrote:
>> http://hackage.haskell.org/trac/ghc/ticket/1695
>
> You haven't suggested a deadline. As the GHC release and ICFP et al  
> are
> coming up, how about 15 October to give people a chance to comment?
>
>> This function is like unzip for a list of Eithers instead of tuples.
>
> Seems fine to me.

For your general amusement, a generalisation:

 > separate :: (Traversable t, Applicative a, Monoid (a x), Monoid (a  
y)) =>
 >             t (Either x y) -> (a x, a y)
 > separate = foldMap (either (pure &&& mempty) (mempty &&& pure))

I don't know whether the applicative/monoid(*) output generalisation is
especially useful, but the shift to any traversable input might come in
handy. Then again, one could always turn the traversable thing into a
list first, using (foldMap pure).

General question: how often does a one-liner need to show up in common
usage to get into the library? You can really go a long way in one line!

(*) foldMap needs a Monoid, so Alternative is not a suitable  
alternative;
as ever, it would be nice to be able to demand (forall x. Monoid (a x))
or some such.

All the best

Conor

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

Re: library submission: Data.Either.unzipEithers :: [Either a b] -> ([a], [b])

Ross Paterson
On Mon, Sep 17, 2007 at 01:51:34PM +0100, Conor McBride wrote:
> For your general amusement, a generalisation:
>
> > separate :: (Traversable t, Applicative a, Monoid (a x), Monoid (a y)) =>
> >             t (Either x y) -> (a x, a y)
> > separate = foldMap (either (pure &&& mempty) (mempty &&& pure))

Or even

newtype Wrap f a = Wrap { unWrap :: f a }

instance Alternative f => Monoid (Wrap f a) where
        mempty = Wrap empty
        Wrap x `mappend` Wrap y = Wrap (x <|> y)

separate :: (Foldable t, Alternative f) => t (Either x y) -> (f x, f y)
separate = (unWrap *** unWrap) .
        foldMap (either ((Wrap . pure) &&& mempty) (mempty &&& (Wrap . pure)))
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: library submission: Data.Either.unzipEithers :: [Either a b] -> ([a], [b])

Jeremy Shaw
In reply to this post by Ian Lynagh
At Mon, 17 Sep 2007 12:57:46 +0100,
Ian Lynagh wrote:
>
> On Fri, Sep 14, 2007 at 01:12:41PM -0700, Jeremy Shaw wrote:
> > http://hackage.haskell.org/trac/ghc/ticket/1695
>
> You haven't suggested a deadline. As the GHC release and ICFP et al are
> coming up, how about 15 October to give people a chance to comment?

October 15 sounds good to me.

j.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries