Discussion about the ConstraintKinds extension

Max Bolingbroke batterseapower at hotmail.com
Tue Oct 18 08:42:53 CEST 2011

On 18 October 2011 02:25, bob zhang <bobzhang1988 at gmail.com> wrote:
>      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?


More information about the Glasgow-haskell-users mailing list