<div dir="ltr">I personally strongly believe in keeping the Applicative and Monad for a type compatible.<div><br></div><div>Otherwise why the heck did we make Applicative a superclass of Monad?</div><div><br></div><div>In this case the thing David wants only makes any difference if you explicitly turn on OverloadedLists, so if you never use that extension you'll never care about the instance anyways.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 11, 2015 at 11:26 AM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Wed, 10 Jun 2015, David Feuer wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
foo = getZipList $ [f,g,h] <$> [a,b,c] <*> [d,e,i]<br>
<br>
looks a lot better than<br>
<br>
bar = getZipList $ ZipList [f,g,h] <$> ZipList [a,b,c] <*> ZipList [d,e,i]<br>
</blockquote>
<br></span>
But the second one is less surprising.<br>
<br>
For my taste it would have been better to give the ZipList semantics to the list type by default, because there are more data types that we can give a ZipList-like Applicative instance. The current non-determinism implementation for Applicative [] and Monad [] could have been used for a special non-determinism list type. But this instance was defined when there was no Applicative. :-(<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<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" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>