#8338: Incoherent instances without -XIncoherentInstances -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): It's not clear where the error is among these files. Here are arguments for or against various places: 1. ''The error is the definition of `ShowInstFor`.'' Packaging up an instance may be awkward, but I think it's useful enough not to ban outright. 2. ''The error is the definition of `incoherent`.'' This function has access to multiple instances of the same type, so how is it to choose among them? But, by making this definition an error, we potentially rule out various desirable programs that operate over datatypes that package instances. Because there's no way to pattern-match on a constructor ''without'' making the instance available, these program would become very awkward to write. 3. ''The error is in the type of `fromB`.'' It could be argued that the type of `fromB` should be `Show One => ShowInstFor One`, thus requiring a coherent instance for `Show One` at any use of `fromB`. This seems awkward, and makes the new, constructor-based constraints feel like the old, stupid, datatype-based constraints. 4. ''The error is in the import statements of module `D`.'' We could prohibit importing two modules that export conflicting instances. But, that would cause interoperability problems between different modules/packages that define overlapping instances. And, without a way to control instance import / export, it would be impossible to rectify this problem. 5. ''There is no error here, just a silly programmer.'' I find this dissatisfying, because it is reasonable for a programmer to assume coherence of instances. Yes, this program is silly, indeed, but I feel like dismissing it is somehow weakening Haskell's claim to offer coherence unless the programmer uses "dangerous" extensions, like `OverlappingInstances` or `IncoherentInstances`. 6. ''This is a feature, not a bug.'' We could say that the program above behaves as expected. If this is the case, we need to document the behavior and then maintain it, which I don't think will be particularly easy. So, what to do? I don't honestly know! It may perhaps be best to let sleeping dogs lie (essentially, option 5), but I wanted to document the problem. I should also note that, in GHC 7.8, this becomes much more apparent, because `Coercible` allows you to do this in just one module! To wit: {{{ {-# LANGUAGE GADTs #-} module G where import GHC.Exts data One = One instance Show One where show _ = "datatype One" newtype Two = MkTwo One instance Show Two where show _ = "datatype Two" data ShowInstFor a = Show a => MkSIF showOne :: ShowInstFor One showOne = MkSIF showTwo :: ShowInstFor Two showTwo = coerce showOne incoherent :: ShowInstFor Two -> String incoherent MkSIF = show (MkTwo One) }}} GHCi reports that `incoherent showTwo` is `"datatype One"` and `incoherent MkSIF` is `"datatype Two"`. Yikes! It might also be worth noting that HEAD produces the opposite output on the original program from 7.6.3 -- the `B` and `C` are reversed in the output. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8338#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8338: Incoherent instances without -XIncoherentInstances -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): In my comment, I was referring to overlapping instances from modules that ''don't'' use `OverlappingInstaces`. Here's how I can see it happening: * Suppose package `dayta` exports a datatype `T` and package `klass` exports a class `C`. * Now, packages `a` and `b` both import `T` and `C` from their respective packages and define an instance `C T`. * Package `c` wants to use the relevant modules from both `a` and `b`. Disaster with eager checking of overlap. I've used packages here instead of modules to emphasize that the authors of all of these parts may be different. From a technical standpoint, replacing "package" with "module" would also work here. I should say I'm not really disagreeing with illissius about eager checking, just drawing out the example of where this might be a problem. I find it very hard to come up with an opinion on this issue that I would feel comfortable defending! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8338#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8338: Incoherent instances without -XIncoherentInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #2356 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Only looking at the title, is this a duplicate of #7296? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8338#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler