[Haskell-cafe] Problem with fundeps.

[Jerzy Karczmarczuk]

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