DoCon and GHC
Serge D. Mechveliani
mechvel at botik.ru
Wed Jan 2 22:41:19 CET 2013
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
(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.
More information about the Glasgow-haskell-users