Hi, Max<div>    Thanks for your reply.</div><div>    I don&#39;t understand your proposal, or can you elaborate on it?</div><div>    Let&#39;s double check,<br>    In my contrived example the definition of class C is like this </div>
<div>        class C c where { foo :: c Int =&gt; ....}</div><div>        class C B =&gt; B a where { ...}</div><div>    will this pass under your proposal?</div><div>    It will bring much more power if this could pass.</div>
<div>    plz let me know if it is committed into the source tree.</div><div>    Many thanks</div><div><div class="gmail_quote">On Tue, Oct 18, 2011 at 2:42 AM, Max Bolingbroke <span dir="ltr">&lt;<a href="mailto:batterseapower@hotmail.com">batterseapower@hotmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 18 October 2011 02:25, bob zhang &lt;<a href="mailto:bobzhang1988@gmail.com">bobzhang1988@gmail.com</a>&gt; wrote:<br>

&gt;      take a contrived example,<br>
&gt;      class C B =&gt; B a where<br>
&gt;      here B :: * -&gt; Constraint,  I think this definition is reasonable,<br>
&gt; since B does not appears in the<br>
&gt;      first position of the context.<br>
<br>
</div>I think you are getting an error where GHC complains about a<br>
superclass cycle. I think this warning is necessary: after all, I<br>
could write the following definition for C:<br>
<br>
&quot;&quot;&quot;<br>
class c Int =&gt; C c where<br>
&quot;&quot;&quot;<br>
<br>
Now I really do have a cycle!<br>
<br>
You are right to say that *some* Cs are OK though. In particular, in a<br>
class &quot;C c&quot; if you don&#39;t mention c in the superclasses there can&#39;t be<br>
a cycle. In fact, the same observation might make sense for detecting<br>
type synonym cycles. Perhaps we could allow:<br>
<br>
&quot;&quot;&quot;<br>
type Foo a = Int<br>
type Bar = Foo Bar<br>
&quot;&quot;&quot;<br>
<br>
I could change the superclass-cycle check to only reject cycles that<br>
actually cause cycles after expansion. So with my proposed C:<br>
<br>
1. Input: C B =&gt; B a. DontExpand = {B}<br>
2. Substitute: B Int =&gt; B a. DontExpand = {B,C}<br>
<br>
We can&#39;t expand further. This is a real cycle and would be rejected.<br>
With a different C:<br>
<br>
&quot;&quot;&quot;<br>
class Eq Int =&gt; C c where<br>
&quot;&quot;&quot;<br>
<br>
1. Input: C B =&gt; B a. DontExpand = {B}<br>
2. Substitute: Eq Int =&gt; B a. DontExpand = {B,C}<br>
3. Substitute: () =&gt; B a. DontExpand = {B, C, Eq}<br>
<br>
Again we can&#39;t expand further, but this time it is because we have<br>
reached (). B would not be rejected.<br>
<br>
I think relaxing the check in this manner would be safe. Would this<br>
change be enough for you to do what you need?<br>
<font color="#888888"><br>
Max<br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>Best, bob<br>
</div>