<div><div dir="auto">Also check out my Freelude package which allows for the definition of restricted arrows like you’ve mentioned:</div><div dir="auto"><br></div><div dir="auto"><a href="https://hackage.haskell.org/package/freelude">https://hackage.haskell.org/package/freelude</a><br></div><br><div class="gmail_quote"><div>On Tue, 27 Feb 2018 at 2:49 pm, Daniel Peebles <<a href="mailto:pumpkingod@gmail.com">pumpkingod@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Also possibly interesting and relevant is Adam Megacz's fascinating (but sadly abandoned) work on generalized arrows and hetmet programming: <a href="http://www.megacz.com/berkeley/garrows/" target="_blank">http://www.megacz.com/berkeley/garrows/</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 26, 2018 at 4:20 PM, Clinton Mead <span><<a href="mailto:clintonmead@gmail.com" target="_blank">clintonmead@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="auto">I’ve implemented a drop in replacement enum class here, which solves your issue among other things:</div><div dir="auto"><br></div><div dir="auto"><a href="https://hackage.haskell.org/package/generic-enum" target="_blank">https://hackage.haskell.org/package/generic-enum</a><br></div><div dir="auto"><br></div><div dir="auto">If it doesn’t have some of the instances you require feel free to send me a pull request.</div></div></div><div class="m_5696750263455137282HOEnZb"><div class="m_5696750263455137282h5"><div><div><br><div class="gmail_quote"><div>On Tue, 27 Feb 2018 at 8:12 am, Will Yager <<a href="mailto:will.yager@gmail.com" target="_blank">will.yager@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To avoid the hellish nightmare of Java’s UnsupportedOperationException-riddled ecosystem, I think we should *very strongly* discourage partial implementations of typeclasses as much as humanly possible. If a type doesn’t fit the typeclass, please don’t pretend it does.<br>
<br>
If it turns out that our typeclasses are divided along bad semantic boundaries (which they clearly are in some cases), we should fix that instead of turning the typeclass landscape into a minefield.<br>
<br>
—Will<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div></div></div>
</div></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div><br></div>
</blockquote></div></div>