Discussion about the ConstraintKinds extension

[bob zhang]

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 at hotmail.com
> wrote:

> 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
>



-- 
Best, bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20111018/8195c0bf/attachment.htm>