<div dir="auto"><div>The class is altogether annoying because it has a Monad superclass instead of a Functor one, excluding perfectly good zippable functors like Map k, IntMap k, and even, ironically, ZipList. What do you mean by the opposite facing information preservation law? And what do you have against munzip, aside from the fact that it looks like it wants to be in the too-lofty-for-its-like circle of Functor?</div><div dir="auto"><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Dec 29, 2016 11:22 PM, "Edward Kmett" <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>No real preference, but this does remind me that <font face="monospace, monospace">MonadZip</font> probably should have the following extra law:</div><div><br><font face="monospace, monospace">uncurry mzip . munzip = id</font></div><div><br></div><div>This law is passed by all current instances and fits the intent of much harder to state opposite facing information preservation law.<br><br>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.</div><div><br></div><div>We can also restate the other information preservation law now that Functor is a superclass of Monad to the rather more succinct</div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">() <$ ma = () <$ mb ==></font>  <span style="font-family:monospace,monospace">munzip (mzip ma mb) = (ma, mb)</span></div><div><br></div><div><div>-Edward</div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div class="elided-text">On Thu, Dec 29, 2016 at 4:54 PM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">MonadZip doesn't really explain how strict mzipWith and (especially)<br>
munzip should be. For example, we could have<br>
<br>
  munzip (Node (a, b) ts) = (Node a as, Node b bs)<br>
    where (as, bs) = Data.List.unzip (map munzip ts)<br>
<br>
or we could make some or all of the pattern matches lazy, or we could<br>
use something lazier than Data.List.unzip, or we could make everything<br>
completely spine-strict (surely unwise).<br>
<br>
Does anyone have a particular preference, or a particular reason to<br>
prefer one choice over others? If not, I think we should go with the<br>
simple version above.<br>
</div><span class="m_3542565658208516943HOEnZb"><font color="#888888"><br>
David Feuer<br>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
</font></span></blockquote></div><br></div>
</blockquote></div><br></div></div></div>