<div dir="ltr">> <span style="font-size:12.8px">Perhaps such warnings could be added to a tool like </span><span class="" style="font-size:12.8px;background-color:rgb(255,255,255)">HLint</span><span style="font-size:12.8px">? I do not think they belong in GHC.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">HLint does not do typechecking so it can only catch operations on tuple literals (which the latest version does), not very useful unfortunately.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 11:28 PM, Kosyrev Serge <span dir="ltr"><<a href="mailto:_deepfire@feelingofgreen.ru" target="_blank">_deepfire@feelingofgreen.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> writes:<br>
> It is actually quite fundamental.<br>
><br>
> Instance resolution works on pattern matching on the type and we need<br>
> all instances to be "global" and not able to be hidden or locally<br>
> overridden to avoid coherence problems.<br>
><br>
> There have been attempts to relax this restriction in the past, none<br>
> of which are particularly satisfactory.<br>
><br>
> * <a href="http://dspace.library.uu.nl/handle/1874/294072" rel="noreferrer" target="_blank">http://dspace.library.uu.nl/handle/1874/294072</a> is probably the most<br>
> recent, but some are quite old.<br>
<br>
</span>Thank you for the education!<br>
<span class=""><br>
> But basically all of them have run afoul of other ways to get "stuck"<br>
> when resolving instances, or needing a vocabulary to track provenance<br>
> of instances, or violate the open world assumptions.<br>
<br>
</span>To my undeducated guess, the paper appears to do a decent job on<br>
covering the alternatives.<br>
<br>
One thing changed since that paper -- type families gained injectivity,<br>
the lack of which was listed as the issue with the associated type families<br>
approach.<br>
<br>
Barring the (huge) question of it changing the kind of Functor, are<br>
there any other problems with it?<br>
<span class="im HOEnZb"><br>
--<br>
с уважениeм / respectfully,<br>
Косырев Сергей<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">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-bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>