I can see why you think it "ought" to work. The instance decls instance (Vspace a v) => Vspace a (c->v) instance Num a => Vspace a a certainly overlap, but GHC does something sensible with the overlap, and that's presumably what you want. BUT the functional-dependency mechanism doesn't have the same resolution mechanism for overlap, and so it thinks both might match, and hence rejects the program. So yet another GHC enhancement might be to combine instance selection with the improvement coming from functional dependencies. Operationally, given a constraint, match it against possible instance decls using only the types *before* the arrow in the fundep (the 'v' in the case of Vspace) once an instance is chosen, the usual overlap-resolution stuff, use the fundep to force the other type(s) to match Hmmm. Has anyone else come across this? Meanwhile, why couldn't you have this: instance (Vspace a v) => Vspace a (c->v) instance Vspace Int Int instance Vspace Float Float etc That is, one instance for each base type? You only have a finite number of base types, so this might not be too bad. Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Jerzy Karczmarczuk | Sent: 03 January 2005 13:02 | To: haskell-cafe@haskell.org | Subject: Re: [Haskell-cafe] Problem with fundeps. | | Henning Thielemann cites myself | | >>I am afraid that something is wrong with my understanding of multi- | >>param classes with dependencies. I tried to generalize one of my old | >>packages for quantum *abstract* computations, where state vectors are | >>defined as functional objects,... | >> | >>class Vspace a v | v -> a | >>where | >> (<+>) :: v -> v -> v | >> (*>) :: a -> v -> v | >> -- etc. | >> | >>instance Vspace a a where | >> (<+>) = (+) | >> (*>) = (*) | >> -- etc. No problem. | >> | >>instance (Vspace a v) => Vspace a (c->v) where | >> f <+> g = \x -> f x <+> g x | >> (a *> f) x = a *> (f x) | >> -- ... | >> | >> | > | >I had the same problem with the same class | > http://www.haskell.org//pipermail/haskell-cafe/2004-March/005979.html | > and thus Dylan Thurston advised me to drop functional dependencies. | > | > | I can't... Otherwise I am killed by ambiguities, later. | | >Here are two implementations using multi-type classes without functional | >dependencies. (They wait for unification, yet, sorry.) | > http://cvs.haskell.org/darcs/numericprelude/VectorSpace.lhs | > http://cvs.haskell.org/darcs/numericprelude/physunit/VectorSpace.hs | > | > | I followed this discussion, and I know your and DT DARC project. | Unfortunately my ambitions are Gargantuan, I want to have | vector spaces which encompass functions over ADT (the config. | specification for a quantum system), functions over functions | (duals and operators), and also functional tensors, which makes | it possible to construct binary functions as a 'product' of two | unary functions; extensible. | | And all this over all kind of scalars. Principally complex, but | also some differential scalars (elements of a differential algebra, | permitting to do the 'automatic differentiation' of Dirac brackets | and also kets, which would permit to use constructively the | differential recurrential definitions of states (Hermite functions, | etc.) For the moment I am obliged to FIX the field of scalars, this | *partly* solves my mathematical troubles. | | I believe in almost all what Ashley Yakeley (and Marcin QK) say, | but in | | >>> instance (Num a)=>Vspace a (c->a) where | >>> instance (Vspace a v) => Vspace a (c->v) where | >> | >> | > | >These are also incompatible. ... | > | the word 'incompatible' should be understood as 'incompatible with | current Haskell', *not* with common sense. Pity. It is obvious that | both: a function any -> scalar, and (any->scalar)->any->scalar | with good arithmetic scalars permit to establish the vector structure. | | Actually, the instances as quoted above produces bizarrily an error | which says that something is less polymorphic than expected; the | overlapping is accepted (apparently). | | Sigh. | | Jerzy Karczmarczuk | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe