#9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): Quoting from the spec: * Eliminate any candidate IX for which both of the following hold: * There is another candidate IY that is strictly more specific; that is, IY is a substitution instance of IX but not vice versa. * Either IX is overlappable or IY is overlapping. Mathematically, this makes a lot of sense. But put on the hat of library writers, and users, and users that don't rtfm. Looking out from under this hat, the one may always wonder whether one should make one's generic instances OVERLAPPABLE or not. If I create a library with type class Bla and {{{ instance Bla a => Bla [a] }}} I could be a nice library writer and spare my users from declaring their Bla String instances as OVERLAPPING, so I'd write {{{ instance {-# OVERLAPPABLE #-} Bla a => Bla [a] }}} Or maybe that would be malicious? I think the current proposal is too sophisticated. There are no convincing examples given in the discussion so far that demonstrate where this sophistication pays off in practice. Keep in mind that 99% of the Haskell users will never study the instance resolution algorithm or its specification, but just flip on/off pragmas until their code goes through. [At least that was my approach: whenever GHC asks for one more LANGUAGE pragma, just throw it in.] -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9242#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler