[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