Thank you for the quick response.  It's very helpful and makes perfect sense now.

On Thu, Aug 7, 2008 at 7:58 PM, Ryan Ingram <ryani.spam@gmail.com> wrote:
Also, you may find it helpful to add

> {-# LANGUAGE KindSignatures #-}

to the top of your program, and start annotating your class and
instance declarations for clarity:

> class Conflict (p :: * -> * -> *) where
>    hasConflict :: p x y -> Bool

Ah, yes we do that sometimes, but not with consistency.
 

On Thu, Aug 7, 2008 at 7:51 PM, Ryan Ingram <ryani.spam@gmail.com> wrote:
> I'm just guessing from this email; I can't see your code.  Let me know
> if I go wrong anywhere.
>
> It looks like you expect your patches to be some type (p :: * -> * ->
> *); that is, a type like
>
>> data Patch x y = ...

Yes, that's right and sorry for not including Patch.
 

>
> However, the instance declaration:
>
>> instance Conflict (p x y) => Conflict (PatchInfoAnd (p x y))
>
> is referring to ANY types
>   p :: * -> * -> * -> * -> *
>   x :: *
>   y :: *
> so that (p x y :: * -> * -> *); that is, a type like this:
>
>> data PatchBroken a b x y = ...
>
> in this case an instance for Conflict (PatchBroken Int Bool) would
> give instances for Conflict (PatchInfoAnd (PatchBroken Int Bool)).

That makes perfect sense.  So, by including x and y in the instance I was dramatically changing the kind inference.  That didn't occur to me earlier, but it does make sense.
 
Thanks!
Jason