Thu, 4 Jan 2001 13:01:56 -0800, Mark P Jones <mpj@cse.ogi.edu> pisze:
I hope now that the problem is becoming clear: this instance declaration is not consistent with the dependency; in the first two lines above, for example, we see two rows that violate the specification because they have the same value of "a", but different values for "b" and "c".
I see. So fundeps are not capable of expressing what I hoped, and what a related but simpler concept I talked about once can express. I wonder if there are practical uses of fundeps which are not expressible by this concept. What I have in mind is the following. A subset of type variables of a class is chosen. Only that subset is used to find an instance for resolving constraints with this class. The instance chosen determines the rest of types. Instances must make this possible, i.e. be non-unifiable wrt. the active subset of type variables. Voila. An extended variant: several such subsets instead of one. Probably each subset should be considered independently, with their results unified. Or something like that. This provides an equivalent of types contained in classes in C++. It does not matter if the passive types in an instance use additional type variables. This is where fundeps fail. Having types with type variables which are never instantiated nor constrained should be equivalent to having ground types! Why, oh why haven't a more friendly and less problematic concept been used, instead of fundeps which forever can't be finished in ghc and have some different semantics in Hugs? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK