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