[GHC] #14292: Coercing between constraints of newtypes

GHC ghc-devs at haskell.org
Thu Sep 28 06:13:15 UTC 2017


#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]:
 > > `IncoherentInstances` is a module-wide setting; and nowadays
 deprecated in favour of the more surgical `{-# INCOHERENT #-}` pragma on
 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


More information about the ghc-tickets mailing list