Dear GHC developers, http://botik.ru/pub/local/Mechveliani/ghcBugs/ghc701preBug.zip contains a bug report on ghc-7.0.0.20100924 tested on Debian Linux, i386-family. Its essence is as follows. At the fragment of --------------------------------------------------------------------- instance (LinSolvRing (Pol a), CommutativeRing a) => -- (1) LinSolvRing (UPol (Pol a)) where gxBasis [] = ([], []) gxBasis fs@(f:_) = let UPol _ p y dP = f (o, n) = (pPPO p, genericLength $ pVars p) (toLex, fromLex) = (reordPol $ lexPPO n, reordPol o) p' = toLex p dP' = upLinSolvRing p' Map.empty s' = cToUPol y dP' p' ... --------------------------------------------------------------------- in the module Pol3_.hs, ghc-7.0.0.20100924 reports that the line of `s' =' needs (EuclideanRing a) and that it cannot deduce it. ghc-6.12.2 compiles this in a correct way: (EuclideanRing a) is not necessary here, while the context (1) is more generic and sufficient. For example, for a = DirectSum Integer Integer, `a' has the instances (1) and has not the instance of Euclidean, and the above code must work. This is the idea of the author of the application; this idea is supported by ghc-6.12.2 and not supported by ghc-7.0.0.20100924. There are the two questions. 1) Whether this intention with instances is correct in the meaning of Haskell + ghcExt (I hope, it is correct, at least, ghc-6.12.2 accepts it). 2) If it is correct, why ghc-7.0.0.20100924 requires (Euclidean a) ? Notices ------- a) This application uses multiparametric classes and overlapping instances (see docon.cabal for language and other options). b) The example code can be reduced further, many times. But I may have time to reduce it maybe only in the middle of December 2010. Regards, ----------------- Serge Mechveliani mechvel@botik.ru