Simon Peyton-Jones
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@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 [..]