testing ghc-6.10-candidate

[Serge D. Mechveliani]

Simon Peyton-Jones <simonpj at microsoft.com>  wrote  on 15 Sep 2008
about  Instances and DoCon
To: "Serge D. Mechveliani" <mechvel at botik.ru>
CC: "cvs-ghc at haskell.org" <cvs-ghc at haskell.org>

> Serge
>
> I take it all back.  I've been persuaded that it's best to accept 
> DoCon-sty le instances as they appear, and I've put quite a bit of 
> work into making it so.
>
> So you should not need to change any code.  Do try the HEAD 
> (any recent snapshot should do) if you can.


All right, I have tested  ghc-6.9.20080910  on  docon-2.12-pre.
Find the source on  
     http://botik.ru/pub/local/Mechveliani/ghcBugs/docon-2.12-pre.zip

It is put there only for testing GHC, and it has the compilation flag 
denotation in  docon.cabal  improved for newer Cabal and ghc-6.10.

The tet shows the followng.

1. It accepts the DoCon-style overlapping instances (as in docon-2.11) 
   -- in the example of  ... => LinSolvRing (Fraction a)
   that you pointed out below.

2. But in several places DoCon has parasitic additions 
   (similar to the below  MulSemigroup (Fraction a))
   to the context for overlapping instances.
   These places are marked in the  docon-2.12-pre  source with  
   'overlaps in ghc'.
   I would like to cancel them, similar as we now cancel the above
   MulSemigroup (Fraction a)  in the context.
   But  ghc-6.9.20080910  does not allow this.
   So, I wonder: what is the difference?

3. `Making' under -O2 reports for the module  Det_.hs  several warnings
    of the kind 
    ...
    [25 of 83] Compiling Det_  ( Det_.hs, dist/build/Det_.o )
    SpecConstr: too many specialisations for one function 
    (see -fspec-constr-count):
    Function: dt{v X1E1R} [lid]
    Specialisations: [([sc_s1E2A{v} [lid], sc_s1E2B{v} [lid],
    ...

    What might this mean?

4. It has improved: it `makes' docon-2.12 under -O fast enough,
   without code explosion, the code is as fast as expected.
   It also `makes' the test Main under -O fast enough (unlike ghc-6.8.3).

5. The same is for -O2. But this does not gain more performance.
   -O2 -fvia-C  also does not gain more performance, but leads to 7 times 
   longer compilation.

   Anyway, I am satisfied with  -O.

Regards,

-----------------
Serge Mechveliani
mechvel at botik.ru


-------------------------------------------------------------------
| Good news: I have cured the massive code-explosion problem you
| encountere  with GHC 6.8.  I'm
| about to commit a patch for that, so it'll be in GHC 6.10.
|
| However, I'm now getting a complaint about overlapping instances 
| (DoCon 2.11).  GHC 6.10 is
| being a bit more consistent about coherence.  Here is one example:
|
| Fraction.hs:124:48:
|     Overlapping instances for MulSemigroup (Fraction a)
|       arising from a use of `inv' at Fraction.hs:124:48-57
|     Matching instances:
|       instance [overlap ok] (GCDRing a) =3D> MulSemigroup (Fraction a)
|         -- Defined at Fract_.hs:438:9-46
|       instance [overlap ok] MulSemigroup (Fraction Integer)
|         -- Defined at Fraction.hs:260:9-39
|     (The choice depends on the instantiation of `a'
|      To pick the first instance above, use -XIncoherentInstances
|      when compiling the other instance declarations)
|
| It's absolutely right!  If you wanted the instance for 
| (MulSemigroup (Fraction Integer)), then
| the call to inv could in principle use 
| MulSemigroup (Fraction Integer) instance, and give
| different behaviour.  (See the user manual stuff about incoherent-
| instances.)
|
| Possible solutions:
| a) add -XAllowIncoherentInstances
| b) make the instance declaration look like
|       instance (MulSemigroup (Fraction a), GCDRing a) => 
|                LinSolvRing (Fraction a)
|    thereby deferring the choice
[..]