#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 simonpj): Austin says: I think Ptr should almost certainly be representational, as it is a case where the actual underlying value is the same, but what it points to is not (I'll ignore castPtr here for a second). This makes me think of something I talked about before with Andres - in general, phantom roles seem somewhat dangerous, and I kind of wonder if they should be inferred by default. Often you see some code along the lines of: {{{ module A ( Bar, newBarInt ) where data Bar a = Bar Int newBarInt :: Int -> Bar Int }}} where A is exported to the client and the module boundary enforces some restrictions on 'Bar', like what types we can instantiate `Bar a` to (the example is dumb but bear with me). In the above example, I believe the `a` in `Bar a` would be inferred at phantom role. The question I have is: what legitimate case would there be for phantom roles like this? Such usage of phantom type parameters seems very common, but in almost *all* cases I can't think of a reason why I would ever want a user to be allowed to `coerce` away the type information, if the `a` parameter was phantom. It seems like in the above example, I would almost certainly want `a` to be representational instead. What other cases exist for legitimate phantom roles such as this where we want this inference? I wonder if instead we should require an explicit role annotation for phantoms in this case - not the other way around. `Ptr` is a similar story - by default it would maybe seem reasonable to be phantom, but that seems like an especially grievous error, given we don't want people to `poke` incorrect values in or something (again, ignoring castPtr for a second, but I think the general idea holds.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9163#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler