readers of this thread might find ghc ticket #1241 relevant
http://hackage.haskell.org/trac/ghc/ticket/1241
class T root pos sel | pos -> root, root -> sel where
f :: pos -> sel -> Bool
instance T root (Any root) sel
But the same applies to the second functional dependency and the type
variable sel. Every instantiation of root determines the instantiation
of sel. And that forbids instance T Int (Any Int) Bool and instance T
Int (Any Int) Int inside the same scope, doesn't it?
Indeed that is your intent, expressed in the functional dependency.
..
then i wonder why that intent is not taken into account in the semantics you
outline, which is widely used, but stems from the days before functional
dependencies.
In our example, an unground
instance |instance T root (Any root) sel| is equivalent to a set of
ground instances where |root| and |sel| are replaced with all possible
ground types. Including
instance T Int (Any Int) Bool
instance T Int (Any Int) Int
These two instances are in the model for
`instance T root (Any root) sel'.
yes, but are they still in the model for that instance _under the dependency_?
instance T root (Any root) sel | Any root->root,root->sel
the difference seems a bit like that between these two qualified lists
[instance T root (Any root) sel | root<-types,sel<-types]
vs
[instance T root (Any root) sel | root<-types,sel<-types,Any
root->root,root->sel]
where one can either complain that some elements of the first list do not
fulfill
some of the qualifiers in the second, or one can filter out those elements, and
see whether the remainder is useable.
or qualified types, if we see functional dependencies as type predicates
f :: T root pos sel => pos -> sel -> Bool
vs
f :: (T root pos sel,pos->root,root->sel) => pos -> sel -> Bool
where one can either complain that f isn't as polymorphic as the first type
suggests,
or one can take the additional type qualifiers into account.
i'm not sure i have an opinion about all this anymore - it used to seem obvious
to me
that FDs, like qualified types, restrict polymorphism. but it has also become
obvious
that not everyone agrees with what i thought was the straightforward
interpretation.
i would be interested, however, if you -or anyone else who hasn't given up on
FDs
yet, could elaborate on what is wrong with this interpretation?
thanks,
claus
ps i don't think that questions like this will simply go away by switching to a
different front-end, like associated types.
A set of instances, an
implementation of a type class, must satisfy the interface, that is,
constraints imposed by the class declaration, including the functional
dependency constraints. In our example, any implementation of T must
satisfy root -> sel constraints. The above two instances show there
exists a model of T where the functional dependency is
violated. That's why both GHC 6.4 and Hugs reject the instance. Again,
it is a mystery why GHC 6.6 accepts it.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
