Proposal: give Ptr a nominal role

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


Carter Schonwald wrote:
> https://ghc.haskell.org/trac/ghc/ticket/9163 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,

    https://ghc.haskell.org/trac/ghc/ticket/9163#comment:38

>>>>On Tue, Oct 30, 2018 at 5:57 PM David Feuer <david.feuer at gmail.com>
>>>>wrote:
>>>>> 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.

Cheers,

Bertram


More information about the Libraries mailing list