overlapping instances in 7.10.1

[Simon Peyton Jones]

Sergei



I finally found time to look into what is happening here.  It's a good illustration of the dangers of overlapping instances.  Here is the setup:



* Module ResEuc_

  * Contains

        instance (...)                    => Ring  (ResidueE a)  <---- (A)

        instance (..., Ring (ResidueE a)) => Field (ResidueE a)  <---- (B)



* Module PFact__

  * Imports Pgcd_, which imports ResEuc_

  * Contains code that needs

       (Field (ResidueE (UPol (ResidueE Integer))))      <------ (X)

  * To solve (X) we use instance (B) from ResEuc_

  * And hence we need to solve (Ring (ResidueE (UPol (ResidueE Integer))))

    which we do using (A) but not (C)





* Module RsePol_

  * Imports PFact__

  * Contains the specialised instance

      instance (...) => Ring (ResidueE (UPol a))     <------ (C)

    which overlaps instance (A)



* Module Main

  * Needs an instance for

       Field (ResidueE (UPol (Residue Integer)))      <------ (Y)



  * Although GHC *could* generate this by instance declarations,

    which it would do using (B) and then using (C),



    instead GHC cleverly sees that it has generated it before,

    in module PFact__, and so uses the one from PFact__. And

    that is what gives rise to your error



So the real problem is that in PFact__, we make an instance (X) that does not see the specialised instance (C).  It *cannot* see that instance because RsePol_ imports PFact__.  So whatever code uses (X) is not going to see the specialised instance.  I bet that this is not what you intend. This may be a latent bug in DoCon.



I solved the problem by combining PFact__ and RsePol_ into a single module.  Then everything works fine.



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-<http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2015.zip>

| may23-2015.zip<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

|

|

|

|

| _______________________________________________

| ghc-tickets mailing list

| ghc-tickets at haskell.org<mailto:ghc-tickets at haskell.org>

| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150613/0811789f/attachment.html>