Comments on: Zipping and Unzipping Functors http://comonad.com/reader/2008/zipping-and-unzipping-functors/ types, (co)monads, substructural logic Sat, 29 Dec 2012 15:18:06 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: anonymous http://comonad.com/reader/2008/zipping-and-unzipping-functors/comment-page-1/#comment-101831 anonymous Wed, 22 Feb 2012 20:29:32 +0000 http://comonad.com/reader/2008/zipping-and-unzipping-functors/#comment-101831 I also want liftPair in Applicative I also want liftPair in Applicative

]]>
By: Edward Kmett http://comonad.com/reader/2008/zipping-and-unzipping-functors/comment-page-1/#comment-9740 Edward Kmett Mon, 22 Jun 2009 21:59:36 +0000 http://comonad.com/reader/2008/zipping-and-unzipping-functors/#comment-9740 @Jake I almost agree. I've had people point out the connection to Applicative on several occasions before, but it falters slightly. There is no requirement for the existence of unit, so your functor need not be pointed. This permits the class of zippable functors to be slightly wider than the class of applicative functors. Secondly the particular near-applicative operation is selected explicitly so it will be a left inverse to unzip. fzip . unfzip = id Since that should hold for any functor to claim to be a member of Zip the definition is narrower than that of Applicative. Using list monad semantics for fzip on [] would fail this law. So Zip is neither a superclass nor a subclass of Applicative. That, at least, was my justification for a zippable functor as an independent concept; I may not have fully articulated the justification back when i wrote this article. @Jake

I almost agree. I’ve had people point out the connection to Applicative on several occasions before, but it falters slightly.

There is no requirement for the existence of unit, so your functor need not be pointed. This permits the class of zippable functors to be slightly wider than the class of applicative functors.

Secondly the particular near-applicative operation is selected explicitly so it will be a left inverse to unzip.

fzip . unfzip = id

Since that should hold for any functor to claim to be a member of Zip the definition is narrower than that of Applicative. Using list monad semantics for fzip on [] would fail this law.

So Zip is neither a superclass nor a subclass of Applicative.

That, at least, was my justification for a zippable functor as an independent concept; I may not have fully articulated the justification back when i wrote this article.

]]>
By: Jake McArthur http://comonad.com/reader/2008/zipping-and-unzipping-functors/comment-page-1/#comment-9675 Jake McArthur Sat, 20 Jun 2009 20:13:02 +0000 http://comonad.com/reader/2008/zipping-and-unzipping-functors/#comment-9675 fzipWith = liftA2, at least ignoring the inverse law for fzip and funzip as you seem to have for [] (where you chose the ZipList semantics) and Maybe. Perhaps the [] and Maybe instances for Zip should be removed, and instances for known Applicatives which follow the inverse law should be added? fzipWith = liftA2, at least ignoring the inverse law for fzip and funzip as you seem to have for [] (where you chose the ZipList semantics) and Maybe. Perhaps the [] and Maybe instances for Zip should be removed, and instances for known Applicatives which follow the inverse law should be added?

]]>
By: The Comonad.Reader » Zapping Adjunctions http://comonad.com/reader/2008/zipping-and-unzipping-functors/comment-page-1/#comment-1615 The Comonad.Reader » Zapping Adjunctions Thu, 05 Jun 2008 19:34:16 +0000 http://comonad.com/reader/2008/zipping-and-unzipping-functors/#comment-1615 [...] In an earlier post about the cofree comonad and the expression problem, I used a typeclass defining a form of duality that enables you to let two functors annihilate each other, letting one select the path whenever the other offered up multiple options. To have a shared set of conventions with the material in Zipping and Unzipping Functors, I have since remodeled that class slightly: [...] [...] In an earlier post about the cofree comonad and the expression problem, I used a typeclass defining a form of duality that enables you to let two functors annihilate each other, letting one select the path whenever the other offered up multiple options. To have a shared set of conventions with the material in Zipping and Unzipping Functors, I have since remodeled that class slightly: [...]

]]>
By: The Comonad.Reader » Cozipping http://comonad.com/reader/2008/zipping-and-unzipping-functors/comment-page-1/#comment-1165 The Comonad.Reader » Cozipping Mon, 05 May 2008 21:48:36 +0000 http://comonad.com/reader/2008/zipping-and-unzipping-functors/#comment-1165 [...] Twan van Laarhoven pointed out that fzip from the other day is a close cousin of applicative chosen to be an inverse of universal construction: unfzip [...] [...] Twan van Laarhoven pointed out that fzip from the other day is a close cousin of applicative chosen to be an inverse of universal construction: unfzip [...]

]]>
By: Twan van Laarhoven http://comonad.com/reader/2008/zipping-and-unzipping-functors/comment-page-1/#comment-1163 Twan van Laarhoven Mon, 05 May 2008 20:53:48 +0000 http://comonad.com/reader/2008/zipping-and-unzipping-functors/#comment-1163 your Zip class is almost the same as Applicative: fzipWith f a b = fmap f a b Your fzip function is suggested in the Applicative paper as making more sense from a category theory perspective. This also raises the question of what exactly fzip should do. How do you say that it should 'zip'? For instance [] is also an applicative functor with the usual Monad-style cartestian product behaviour. Specifying that unfzip is the inverse of fzip is a good idea. For [] fzip is only a right inverse of unfzip, since you could zip lists of different lengths. The same holds for Maybe: funzip (fzip (Just x) Nothing) /= (Just x, Nothing). your Zip class is almost the same as Applicative:

fzipWith f a b = fmap f a b

Your fzip function is suggested in the Applicative paper as making more sense from a category theory perspective.

This also raises the question of what exactly fzip should do. How do you say that it should ‘zip’? For instance [] is also an applicative functor with the usual Monad-style cartestian product behaviour.

Specifying that unfzip is the inverse of fzip is a good idea. For [] fzip is only a right inverse of unfzip, since you could zip lists of different lengths. The same holds for Maybe: funzip (fzip (Just x) Nothing) /= (Just x, Nothing).

]]>