overlapping instances in 7.10.1

[Sergei Meshveliani]

On Tue, 2015-06-16 at 00:03 +0400, Sergei Meshveliani wrote:

> [..]
> 2) At least  ghc-7.8.3  and  ghc-7.10.1  do the same in this example. 
>    May be, you can change this example a bit to make  ghc-7.8.3 and  
>    ghc-7.10.1 diverse, so that my example bug becomes visible?
>    (they diverse on  7.10.1-errReport-may23-2015.zip  but this bunch 
>     of modules is too complex).

(this is in the end of my last letter).


I am trying now to reduce the report of  7.10.1-errReport-may23-2015.zip
into something simple. 
And discover that  Main  yields a different result for  -Onot.
Probably,  DoCon-2.12.1  will run correct under  -Onot.
For me, this is not important, because  -O  is desirable anyway.
But for the GHC developers this effect may present some information.

Regards,

------
Sergei



> On Mon, 2015-06-15 at 09:29 +0000, Simon Peyton Jones wrote:
> > |  This is why I think that  ghc-7.8.3  treats the OI notion in a more
> > |  natural way than ghc-7.10.1 does.
> > |  May be, ghc-7.10.1 has a better technical tool for this, but  ghc-
> > |  7.8.3 corresponds to a natural notion of OI.
> > |  
> > |  Can GHC return to a natural OI notion?
> > |  Or am I missing something?
> > 
> > Well it all depends what you mean by "natural". To me it is profoundly 
> > un-natural to deliberately have the same type-class constraint solved in 
> > two different ways in the same program!
> > 
> > To require this would prevent cross-module specialisation. If I have	
> > 	f :: C a => a -> a
> > in one module, and I specialise it to
> > 	f_spec :: [Int] -> [Int]
> > in one module, I want to be free to re-use that specialisation in other modules. 
> >  But under your "natural" story, I cannot do that, because (C [Int]) might be 
> > resolved differently there.
> 
> 
> Now, I give a simple (and a very contrived) example illustrating of how
> overlapping instances  (OI)
> are used in DoCon.
> Also this example is made after the sample that Simon has given in his
> recent letter:
> 
> [..]

> 2) At least  ghc-7.8.3  and  ghc-7.10.1  do the same in this example. 
>    May be, you can change this example a bit to make  ghc-7.8.3 and  
>    ghc-7.10.1 diverse, so that my example bug becomes visible?
>    (they diverse on  7.10.1-errReport-may23-2015.zip  but this bunch of 
>     modules is too complex).
[..]