overlapping instances in 7.10.1

[Simon Peyton Jones]

|  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.

I'd be interested in what others think.  I've started
	https://ghc.haskell.org/trac/ghc/ticket/10526
to collect these points.

Meanwhile, Sergei, it's clear how to fix docon, so you are no longer stuck.

Simon

|  
|  
|  
|  >   I bet that this is not what you intend. This may be a latent bug
|  in
|  > DoCon.
|  
|  If I am not missing anything in my above discourse, then DoCon is all
|  right at this point.
|  
|  
|  > I solved the problem by combining PFact__ and RsePol_ into a single
|  > module.  Then everything works fine.
|  
|  I think that this approach will generally lead to great difficulties
|  in
|  composing an application.
|  
|  Please, consider my above explanation and tell me whether I am missing
|  something.
|  
|  Regards,
|  
|  ------
|  Sergei
|  
|  
|  
|  > What are the general lessons here?
|  >
|  >        GHC generally assumes that if it generates (C T) in one
|  place,
|  > then it can use that anywhere in the program that (C T) is needed.
|  > That is, there is only one (C T) dictionary.
|  >
|  >
|  > ·       But suppose you have overlapping instance in different
|  > modules; say
|  >
|  > module A where instance C [a]
|  >
|  > module B where import A; instance C [Maybe a]
|  >
|  > If you use (C [Maybe Int]) in A, then of course we won’t see the
|  > instance in B.  So you’ll get a different dictionary than if you
|  > compute C [Maybe Int] in module B.
|  >
|  >
|  >
|  > In short, overlapping instances are OK, but it’s best to put them in
|  > the same module as the instances they overlap.
|  >
|  >
|  >
|  > Could GHC behave as if all instances were calculated afresh in the
|  > module being compiled.  Yes, of course it could, but at the cost of
|  > losing the benefit of cross-module specialisation.  An overloaded
|  > function specialised at, say, [Int] in one module could not be re-
|  used
|  > in another in case the instances changed.
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  
|  > | -----Original Message-----
|  > | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On
|  Behalf
|  > Of
|  > | Sergei Meshveliani
|  > | Sent: 23 May 2015 22:08
|  > | To: glasgow-haskell-users at haskell.org
|  > | Cc: glasgow-haskell-bugs at haskell.org
|  > | Subject: overlapping instances in 7.10.1
|  
|  > | Dear GHC developers,
|  > |
|  > | This request overrides my previous one of  "7.10.1-err..."
|  > | (it is simpler and more precise).
|  > | The archive
|  
|  > | http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-
|  errReport-
|  > | may23-2015.zip
|  > |
|  > | presents a question about  ghc-7.10.1.
|  >
|  > | Make it, please, with  ghc-7.10.1  by
|  
|  > |          ghc $doconCpOpt -O --make Main
|  > | ,
|  > | $doconCpOpt =
|  
|  > |  -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports
|  > |  -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns
|  > |  -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances
|  > |  -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30
|  >
|  > |
|  > | as it is written there in  README.txt.
|  > | README.txt  explains which two instances are wrongly resolved
|  > | -- as I expect.
|  
|  > | In  ghc-7.8.2  they are resolved in a correct way
|  > | (and there is a different pragma syntax).
|  > | I conclude this from running the test in  docon-2.12.
|  
|  > | Am I missing something?
|  > | Please, advise,
|  
|  > | ------
|  > | Sergei
|