Hello, There is no problem if an instances uses a type family in it's assumption---the instances should be accepted only if GHC can see enough of the definition of the type family to ensure that the functional dependency holds. This is exactly the same as what it would do to check that a super class constraint holds.
-Iavor On Wed, May 30, 2012 at 11:14 PM, Etienne Laurin <[email protected]> wrote: > 2012/5/31 Iavor Diatchki <[email protected]>: > > Hello, > > > > the notion of a functional dependency is well established, and it was > used > > well before it was introduced to Haskell (for example, take a look > > at http://en.wikipedia.org/wiki/Functional_dependency). So I'd be > weary to > > redefine it lightly. > > Indeed, GHC's functional dependencies are not the same. I see you have > already talked about this on the GHC bug tracker. > > http://hackage.haskell.org/trac/ghc/ticket/1241 > > > 1. Check that an instance is consistent with itself. For example, this > should be rejected: > > > > instance C a b > > > > because it allows C Int Bool and C Int Char which violate the functional > dependency. > > This check may not always be as straightforward. When would this be a > valid instance? > > instance K a b ⇒ C a b > > With a few extra extensions, K could be a type family. > > C currently has the kind (a -> b -> Constraint), with no mention of > functional dependencies. Perhaps the kind of C should include the > functional dependencies of C? > > Etienne Laurin >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
