I recently wrote an instance for Zip3 Maybe for a project, and I noticed that the type signatures suggest that every applicative functor could have a valid instance for Zip3 (and vice versa.) There's even a commented-out default implementation for unzip3 in the code that would allow for this instance:
instance Applicative f => Zip3 f where
zipWith3 f a b c d = f <$> a <*> b <*> c <*> d
unzip3 = fmap (\(x,_,_)->x) &&& fmap (\(_,x,_)->x) &&& fmap (\(_,_,x)->x)
I vaguely remember reading in the docs somewhere that this instance isn't defined in general because unzip3 would hold 3 references to the original functor value, but I think this could be avoided by using seq to kill some of the thunking. Does it not work that way? Is there another reason to not define this instance (and others for Zip4, etc.?) Would you take a PR that does this?
Thanks for maintaining the library!
I recently wrote an instance for
Zip3 Maybefor a project, and I noticed that the type signatures suggest that every applicative functor could have a valid instance forZip3(and vice versa.) There's even a commented-out default implementation forunzip3in the code that would allow for this instance:I vaguely remember reading in the docs somewhere that this instance isn't defined in general because
unzip3would hold 3 references to the original functor value, but I think this could be avoided by usingseqto kill some of the thunking. Does it not work that way? Is there another reason to not define this instance (and others forZip4, etc.?) Would you take a PR that does this?