MonadZip for Data.Tree

Edward Kmett ekmett at gmail.com
Fri Dec 30 04:22:15 UTC 2016


No real preference, but this does remind me that MonadZip probably should
have the following extra law:

uncurry mzip . munzip = id

This law is passed by all current instances and fits the intent of much
harder to state opposite facing information preservation law.

Since we continue to insist on this class containing the annoying munzip
operation, this law is actually far easier to demonstrate than the existing
law.

We can also restate the other information preservation law now that Functor
is a superclass of Monad to the rather more succinct

() <$ ma = () <$ mb ==>  munzip (mzip ma mb) = (ma, mb)

-Edward

On Thu, Dec 29, 2016 at 4:54 PM, David Feuer <david.feuer at gmail.com> wrote:

> MonadZip doesn't really explain how strict mzipWith and (especially)
> munzip should be. For example, we could have
>
>   munzip (Node (a, b) ts) = (Node a as, Node b bs)
>     where (as, bs) = Data.List.unzip (map munzip ts)
>
> or we could make some or all of the pattern matches lazy, or we could
> use something lazier than Data.List.unzip, or we could make everything
> completely spine-strict (surely unwise).
>
> Does anyone have a particular preference, or a particular reason to
> prefer one choice over others? If not, I think we should go with the
> simple version above.
>
> David Feuer
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20161229/82e0e178/attachment.html>


More information about the Libraries mailing list