Hi, Max Thanks for your reply.
I don't understand your proposal, or can you elaborate on it?
Let's double check,
In my contrived example the definition of class C is like this
class C c where { foo :: c Int => ....}
class C B => B a where { ...}
will this pass under your proposal?
It will bring much more power if this could pass.
plz let me know if it is committed into the source tree.
Many thanks
On Tue, Oct 18, 2011 at 2:42 AM, Max Bolingbroke
<batterseapower@hotmail.com> wrote:
On 18 October 2011 02:25, bob zhang <
bobzhang1988@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.
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
--
Best, bob