[Haskellcafe] Problem with fundeps.
Simon PeytonJones
simonpj at microsoft.com
Tue Jan 4 08:00:43 EST 2005
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 functionaldependency
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 overlapresolution 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: haskellcafebounces at haskell.org
[mailto:haskellcafebounces at haskell.org] On Behalf Of
 Jerzy Karczmarczuk
 Sent: 03 January 2005 13:02
 To: haskellcafe at haskell.org
 Subject: Re: [Haskellcafe] 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/haskellcafe/2004March/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 multitype 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



 _______________________________________________
 HaskellCafe mailing list
 HaskellCafe at haskell.org
 http://www.haskell.org/mailman/listinfo/haskellcafe
More information about the HaskellCafe
mailing list