Proposal: give Ptr a nominal role

Bertram Felgenhauer bertram.felgenhauer at
Sun Nov 4 12:01:00 UTC 2018

Carter Schonwald wrote:
> seems to talk about *why* Ptr
> being phantom actually has a pretty measurable impact on code. (cast ptr
> becomes a noop and this has a measurable impact on a number of application
> measures)

David's point, I believe, is that the same performance problem could
have been solved by turning Ptr into a newtype, without giving up the
representational that it had before. In fact he brought this up in the
same trac ticket,

>>>>On Tue, Oct 30, 2018 at 5:57 PM David Feuer <david.feuer at>
>>>>> Thankfully, we have enough power to fix this now.
>>>>>     data Addr = Ptr_ Addr#
>>>>>     newtype Ptr a = Ptr_ Addr
>>>>>     type role Ptr nominal
>>>>>     pattern Ptr :: Addr# -> Ptr a
>>>>>     pattern Ptr a# = Ptr_ (Addr a#)
>>>>>     castPtr :: Ptr a -> Ptr b
>>>>>     castPtr (Ptr a) = Ptr a
>>>>>     ptrCoercible
>>>>>       :: ((forall a b. Coercible (Ptr a) (Ptr b)) => r)
>>>>>       -> r
>>>>>     ptrCoercible r = r
>>>>>     ptrCoercion :: Coercion (Ptr a) (Ptr b)
>>>>>     ptrCoercion = Coercion
>>>>> I propose that we do this.

This will break some imports, since

  import GHC.Ptr (Ptr (..))

will not import the pattern synonym. This is how Ptr is imported in
both bytestring and vector. But it's not a big deal, I suppose.



More information about the Libraries mailing list