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?
Max
More information about the Glasgow-haskell-users
mailing list