On Wed, Jan 02, 2013 at 08:23:37PM +0000, Simon Peyton-Jones wrote:
| > The solution is to add (EuclideanRing k) to the type sig of cubicExt. | > Then it compiles all the way up to the top. | | But the DoCon declares | class (EuclideanRing a, FactorizationRing a) => Field a | | (EuclideanRing is a superclass for Field), | and the test declares | cubicExt :: (Field k, FactorizationRing (UPol k)) => | k -> k -> Domains1 k -> (Domains1 (E k), [E k], k -> E k) | | So, why the compiler does not `extract' EuclideanRing k from Field k
I made a mistake. I should have said "add (EuclideanRing (Pol k)) to the type sig of cubicExt".
GHC can't extract EuclideanRing (Pol k) from Field k except by using one of the two (overlapping) instances.
I don't know why 7.4 accepts it, but I'm not inclined to investigate... looks like a bug in 7.4.
ghc-7.4.1 may use a special trick, but is correct.
I should have said "add (EuclideanRing (Pol k)) to the type sig of cubicExt".
(1) UPol is for an Univariate Polynomial, and Pol is for an Multivariate Polynomial (more generic). (2) DoCon declares Field k => EuclideanRing (UPol k). (3) DoCon does not have the instance Field k => EuclideanRing (Pol k), because it is not correct in algebra. Haskell+Glasgow can not derive EuclideanRing (Pol k) from Field k in the DoCon code. (4) In cubicExt, Haskell+Glasgow derives a weaker instances: LinSolvRing (Pol k), LinSolvRing (Pol (UPol k)), LinSolvRing (UPol (Pol k)) -- and this is sufficient. This is the intension of DoCon + cubicExt, and ghc-7.4.1 supports this (may be, by some tricky designп, I do not know). (5) I can add EuclideanRing (UPol k) to the sig of cubicExt (even though Haskell+Glasgow must derive it), but I expect that this would not help. (6) I can not add EuclideanRing (Pol k) to the sig of cubicExt, because this is not correct by the algebraic design. cubicExt indeed uses rather a complicated set of instances. I do not know, may be I need to think of how to reorganize the design for porting it to ghc-7.6.2. ghc-7.4.1 did the job correctly, and it is difficult to change the coresponding part of the DoCon design. And if you happen to find how to meet (1) -- (6), then I would not need to re-design the thing. Regards, ------ Sergei