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