Add `Data.Functor.unzip`

[ocharles]

Currently Data.List.NonEmpty defines:

-- | The 'unzip' function is the inverse of the 'zip' function.
unzip :: Functor f => f (a,b) -> (f a, f b)
unzip xs = (fst <$> xs, snd <$> xs)

But this is a very strange place for such a generally useful function.

I'd like to propose that Data.Functor gains this function. I don't feel strongly on whether it should be a new definition, nor what should happen with Data.List.NonEmpty.unzip, only that after this proposal I can do:

import Data.Functor (unzip)

[treeowl]

The version in Data.Functor can be no better than that one. Data.Traversable can do rather more, in principle, using something like Data.Biapplicative.traverseBia.

[ocharles]

Ok, I am fine with the version I proposed. Are you saying it is not suitable for Data.Functor?

[treeowl]

I'm just saying that there are more and more options the more is known about the structure. The bare minimum version would fit very well in Data.Functor, but I don't think I'd personally find it very useful.

[ekmett]

It is also worth noting the existence of munzip in Control.Monad.Zip, which is almost always the same as the functor-based definition. Except it uses liftM internally and inefficiently for historical reasons. (I was able to come up with a couple of monads for which it actually helped to have it in the class, but they are decidedly weird.) I'm not calling for concrete action around this fact, just raising awareness.

[phadej]

unzip could be a member of Functor type-class, for the same reason (<$) is, there can be more efficient implementations: [a] and NonEmpty a come to mind immediately.

And as there is default implementation, it shouldn't be too intrusive change either.

[Ericson2314]

I would move the function, and only then worry about making it a class member. Baby steps.

[treeowl]

@phadej, I'm not sure making it a method magically solves the problems. The strictness and other properties of the most "obvious" unzip depend on the type, which makes a class method hard to reason about. Furthermore, one may want less-obvious unzips in certain cases. Ignoring the strictness of the outermost pair (because it's boring), there's just one unzip that makes sense for every Functor, which is also boring. There are two additional ones that make sense for every Traversable. Some types have sensible unzips that are none of these, such as lists (but, perhaps surprisingly, not Data.Sequence sequences). Note that while the lazy Traversable unzip has less space leak potential than the Functor one, it will actually use significantly more memory in certain call site contexts.

[phadej]

@treeowl it doesn't need to solve all the problems. Is there drawbacks of unzip being a class member?

No ordinary person will be able to choose from three+ different unzips for lists.

[treeowl]

@phadej, I'm concerned for the poor programmer who has to implement the method. From a practical perspective, I think most applications/call sites will want one of three things.

1. Totally eager unzipping. This is natural for arrays, and might make sense for other things if they're sufficiently short.
2. Something lazier than that, but designed to avoid leaks.

Another concern: I don't actually think non-traversable functors necessarily have sensible unzips. For example, you can use the simple fmap thing to "unzip" an IO action, but that doesn't strike me as something very reasonable to do.

[phadej]

@treeowl

but that doesn't strike me as something very reasonable to do.

So are you against adding general

unzip :: Functor f => f (a,b) -> (f a, f b)
unzip xs = (fst <$> xs, snd <$> xs)

as it can be used with IO?

[phadej]

unzipWith :: (c -> (a, b)) -> f  c -> (f a, f b)

Is slightly more general, and composes better. (Think a variant for Compose).

[ocharles]

Perhaps it would help for me to supply a bit more motivation for why I want this? Here is a use of Data.List.NonEmpty.unzip in my current work project (none of which are used on NonEmpty lists):

  let (onFailedToSaveImage, onSuccessfullySavedImage) =
        unzip $
          inputs.onSavedImage <&> \e ->
            split $
              e <&> \(image, res) -> do
                case res of
                  Left e -> Left e
                  Right () -> Right image

Where the thing being unziped here (inputs.onSavedImage ..) is :: Cameras (Event SomeException, Event ()). Cameras is a two-tuple as a functor, and Event is from reactive-banana.

This isn't much, but it felt wrong to import Data.List.NonEmpty for this, and I didn't want to depend on any other libraries or have to define unzip to make this code work.

[treeowl]

@phadej I don't think I'm against that... but I have doubts about a class method that doesn't make much sense for a pretty large category of instances. It makes me nervous, anyway. I'd be substantially less nervous about adding one for Traversable.

[treeowl]

But Traversable isn't quite right either, is it, because that requires an ordering. Perhaps morally it belongs in some class between? Or does unzipping IO make more sense than I'm giving it credit for?