Hi,<br><br><div class="gmail_quote">2011/6/21 Simon Peyton-Jones <span dir="ltr">&lt;<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">







<div link="blue" vlink="purple" lang="EN-GB">
<div><div class="im">
<p class="MsoNormal" style="margin-left:36.0pt">I suppose that could be changed, yes, but what exactly are we trying to solve here? One can already specify different behavior for constructors with/without named fields. Are we trying to avoid OverlappingInstances?
 Then yes, this might help, but I&#39;m not sure this change alone would make all generic programming possible without OverlappingInstances.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36.0pt"><u></u> <u></u></p>
</div><p class="MsoNormal">To be clear, I wasn’t advocating a change, just saying that there’s no GHC-HQ imperative to avoid them.<u></u><u></u></p></div></div></blockquote><div><br>Ah, right. I would also be happy to help improving the current generics mechanism.<br>

<br>Also, reading up on <a href="http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap">OverlappingInstances in the User&#39;s Guide</a> (namely the incoherence example without IncoherentInstances) made me see the evilness of the current implementation. But I would only favor deprecating OverlappingInstances when there is a clear alternative supporting (and potentially improving) the current uses for OverlappingInstances.<br>

<br><br>Pedro<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-GB"><div><p class="MsoNormal">

</p>
<p class="MsoNormal"><br>
Simon<span style="font-size:11.0pt;color:#1F497D"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt" lang="EN-US">From:</span></b><span style="font-size:10.0pt" lang="EN-US"> José Pedro Magalhães [mailto:<a href="mailto:jpm@cs.uu.nl" target="_blank">jpm@cs.uu.nl</a>]
<br>
<b>Sent:</b> 21 June 2011 09:01<br>
<b>To:</b> Simon Peyton-Jones<br>
<b>Cc:</b> David Mazieres expires 2011-07-21 PDT; <a href="mailto:oleg@okmij.org" target="_blank">oleg@okmij.org</a>; <a href="mailto:ccshan@rutgers.edu" target="_blank">ccshan@rutgers.edu</a>; Dimitrios Vytiniotis; <a href="mailto:haskell-prime@haskell.org" target="_blank">haskell-prime@haskell.org</a></span></p>

<div class="im"><br>
<b>Subject:</b> Re: TypeFamilies vs. FunctionalDependencies &amp; type-level recursion<u></u><u></u></div><p></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi,<u></u><u></u></p><div><div></div><div class="h5">
<div>
<p class="MsoNormal">2011/6/21 Simon Peyton-Jones &lt;<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>&gt;<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">| One thing you could do to help in this specific case would be to use a<br>
| different M1 tag--e.g., M1 S ... for selectors and M1 NS ... for<br>
| fields without selectors (or K1 NS).  I presume you&#39;ve already<br>
| considered this and/or it&#39;s too late to make such a change.  (Or to<br>
| move the distinction up to the constructor with two different<br>
| constructor tags, CR and CN for record and no-record.)<u></u><u></u></p>
</div>
<p class="MsoNormal">I don&#39;t think it&#39;s too late to make a change.  The stuff has only just gone in, so it&#39;s still very malleable.  There may be other considerations, but legacy code isn&#39;t one of them!<u></u><u></u></p>


<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
I suppose that could be changed, yes, but what exactly are we trying to solve here? One can already specify different behavior for constructors with/without named fields. Are we trying to avoid OverlappingInstances? Then yes, this might help, but I&#39;m not sure
 this change alone would make all generic programming possible without OverlappingInstances.<br>
<br>
(Also, I always thought UndecidableInstances were &quot;more evil&quot;, in some sense, and this change does nothing to remove the use of UndecidableInstances for generic programming.)<br>
<br>
<br>
Cheers,<br>
Pedro<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div></div></div>
</div>
</div>

</blockquote></div><br>