#13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm a bit unclear on both parts of the plan. * You write "special-case GHC.Exts so that it is always visible". Is this a code change? Are we keeping definition 2 for visibility of class instances for now? We don't really have to do anything about GHC.Exts for now, because: 1. For class instance lookup, the `IsList` instances are already treated as visible because they are non-orphan. 2. For type family instance lookup, the plan is to apply the same non- orphan rule as for class instance lookup, so the `Item` instances will be treated as visible too. 3. For type family consistency checking, we need to make sure that a. All family instances that are made visible in this way are consistent with other visible instances. But there's no actual problem here, because in order to ''define'' an instance of `IsList` you still need to import `GHC.Exts`, and then `GHC.Exts` will be in the set of transitively imported family instance modules that gets checked for consistency. (The way there could have been a problem here is if the instances in question were non-orphan because they defined an instance that mentions a type defined in the module, of a type family that is defined in another module.) b. Since the desugarer is going to insert a call to `GHC.Exts.fromListN` into our module `M`, we also need to make sure that the definition of `fromListN` doesn't depend on some other type family instances that were visible in `GHC.Exts`, which might conflict with ones that are visible in our module `M`. But `fromListN` is just a class method, so surely there's no problem there either. In short, `GHC.Exts` is special-cased in the correctness proof, not in the compiler. But there could be other situations in which the arguments of 3a and 3b don't apply, so a better long-term plan is in order. And #13251 already gives an example. * "But, if we look at how the compiler handles finding instances of wired in things"... This sounds reasonable, but the problem here is not just about wired-in things. `IsList` is known-key, not wired-in; and the example using TH in #13251 is neither. In any case, since #13251 is its own ticket, I'll continue here with the short-term plan of using the same rules for type family instance visibility as for class instance visibility. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13102#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler