`IncoherentInstances` is a module-wide setting; and nowadays deprecated in favour of the more surgical `{-# INCOHERENT #-}` pragma on
#14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 AntC): Replying to [comment:4 RyanGlScott]: the instance.
Does that also apply for the role mungling?
As far as I know, you do need to enable the `IncoherentInstances` extension proper in order to assign non-nominal roles to class parameters,
Thanks Ryan, yes that's what the User Guide says -- if I look up about Roles, section 9.36. Then BTW the User Guide for `IncoherentInstances` section 9.8.3.6 doesn't mention it has anything to do with Roles, but only with Overlaps. Likewise the doco for `-XIncoherentInstances` compiler flag section 6.6.12; which also implies `XOverlappingInstances`. Does it?
as the `{-# INCOHERENT #-}` pragma only works for instance declarations, not class declarations. (This might be partly why you don't get a deprecation warning when enabling `IncoherentInstances`, but you do with `OverlappingInstances`, which doesn't have a dual purpose like `IncoherentInstances` does.)
Hmm. Certainly you could say that `IncoherentInstances` is a poor choice of name if what it means is `IncoherentOverlaps`. Giving it a "dual purpose" seems like asking for trouble. Why wasn't there a new flag for `IncoherentInstanceRoles`? (And "dual purpose" seems in violation of the principles in the debate just going on about derived instances for `EmptyDataDecls`.) .
How does the `{-# INCOHERENT #-}` pragma go for `StandaloneDeriving`
or `GeneralizedNewtypeDeriving`? It seems to be accepted by GHC OK, does it have the right effect? (It's hard to put together a test case.)
I'm not sure I understand the question. Derived instances never use `{-#
INCOHERENT #-}` (or even `{-# OVERLAPS #-}`/`{-# OVERLAPPING #-}`/`{-# OVERLAPPABLE #-}`, for that matter) in their emitted code, ... I managed to get GHC to accept Standalone {{{ deriving instance {-# INCOHERENT #-} Num USD }}} I think you're saying: that pragma would be ignored; wouldn't enable the incoherent Role (in absence of `IncoherentInstances` on the module); would complain if that instance overlaps. OK there couldn't be an overlap for USD; let's say `deriving instance {-# INCOHERENT #-} Num a => Num (N a)` where there's also a hand-crafted `instance {-# OVERLAPS #-} Num (N Int) where ...`, for `newtype N a`. If the module has `IncoherentInstances`, do both those instances get accepted even without the pragmas? (Or perhaps a more devious scenario where one of the instances is imported.)
... if that's what you're wondering.
I'm wondering about the combination of these "dual purposes". Suppose I want GHC to trust the Roles on my instances; but I don't want instances to overlap. That is, if I by accident write instances that overlap, I want GHC to reject them. Thinking out loud: I perhaps want the effect of `IncoherentInstances` on the module (to get Role mungling); but `{-# NOOVERLAPS #-}` on the instance -- no such pragma at the moment. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14292#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler