#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 illissius): I might be missing something important, but it seems to me that the answer is very obviously 4. I'm not familiar with the precise language of the standard, but I always understood the rule to be very simple: "thou shalt have no more than one instance of a class for a type in thy program". We're blatantly violating this rule, the question is why GHC is not catching us. I think the answer is that you've come up with a way to distinguish GHC's lazy checking of instance overlap from other compilers' eager checking, to GHC's detriment. There's no use of a `Show One` instance in `D`, so GHC doesn't bother to investigate it. If overlap were checked eagerly at imports instead of lazily at use sites, the error would be caught. Obviously there must be a reason why GHC does lazy rather than eager checking (and I think it might have something to do with `Overlapping`- and `IncoherentInstances`?), but I don't know the specifics. What would break if overlap checking were eager?
We could prohibit importing two modules that export conflicting instances. But, that would cause interoperability problems between different modules/packages that define overlapping instances.
Do you mean overlapping instances using `OverlappingInstances`, or without it? In the latter case I think it's the absence of interoperability problems that should count as a bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8338#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler