CODEWITHSUNDEEP
haskellghctypeclasscabaloverlapping-instances
Graham Leach-Krouse
Graham Leach-Krouse

Reputation: 173

In GHC-8.2.2, can overlapping instance resolution depend on whether a file is included as an exposed module?

I'm encountering the following hard to understand behavior from GHC-8.2.2

I have some overlapping typeclass instances. No incoherent typeclass instances. There's a certain typeclass instance of the form, roughly,

instance (C f h, C g h) => D1 (D2 f g) h

where C has overlapping instances. When I load my project into stack repl, all is well. The context of this instance is resolved to the instances of C I'm looking for.

If I create a file test.hs which imports a datatype falling under the instance above, all is not well. When I load that into stack repl, and call an operation of D1, then it's clear that the context of the instance of D1 is being resolved to the "wrong" instance of C.

What's especially strange is that if I add test.hs to my project as an exposed module, then reload it into the repl with no other changes, then the context of the instance above is resolved to the "right" instance of C.

I do not see this behavior with GHC-7.10.3, 8.0.1, 8.0.2, or with 8.4.3. Perhaps this is related to this bug?

But I'm not using incoherent instances, which is what that bug seems to involve. I am using a fair number of language extensions in the module where the instance above occurs: 

{-#LANGUAGE TypeFamilies, UndecidableInstances, FlexibleInstances, MultiParamTypeClasses, FunctionalDependencies, GADTs,  DataKinds, PolyKinds, TypeOperators, PatternSynonyms, RankNTypes, FlexibleContexts, ScopedTypeVariables, DefaultSignatures #-}

I don't yet have a minimal example. A minimal example of the behavior can be found at GHC-Repro. Run test.sh to see the phenomenon. What I would like to know is:

  1. Whether this might conceivably be intended behavior by GHC, and I'm just doing something wrong.
  2. If I am doing something wrong, what I might do to select the "right" instance when importing stuff from my project into other projects.

This issue is now being tracked at: https://ghc.haskell.org/trac/ghc/ticket/15599

Upvotes: 3

Views: 118

Answers (0)

Related Questions