DoCon and GHC

[Serge D. Mechveliani]

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