#9163: Ptr should have a phantom role -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 rwbarton): +1 from me on making `Ptr`'s role phantom. But especially I don't think it should be ''exactly'' representational; either phantom or nominal must be better. A `Ptr a` is not actually a pointer to a Haskell heap object of type `a`, for any type `a`. Neither the representation of the `Ptr a` itself nor the representation of the thing-being-pointed-to depends on the ''representation'' of `a` specifically. I might define a `newtype BigEndianInt = BigEndianInt Int` and write a `Storable` instance that uses a big-endian format when `peek`ing or `poke`ing. Then it isn't any more valid to cast from `Ptr Int` to `Ptr BigEndianInt` than it is to cast from `Ptr Int` to `Ptr Double`. Similar comments probably apply to Austin's hypothetical example of an inferred phantom role. If the library author does not want `Bar` to have a phantom role, they probably do not want it to have a representational role either. But it's hard to say without a more fledged-out example. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9163#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler