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