I realized that the current representation is kind of balanced on a knife
edge, efficiency-wise. There's probably no way to make one thing faster
without slowing down another: there are just too many things a ForeignPtr
could be trying to represent.
On Thu, Sep 6, 2018, 3:15 AM Simon Marlow
On Behalf Of David Feuer
Sent: 05 September 2018 00:23
To: ghc-devs
Subject: ForeignPtr representation
I'm trying, and failing, to understand why ForeignPtr is defined the way it is.
It all seems rather complicated and redundant. I was thinking we might want to
switch to something simpler and more
I'm trying, and failing, to understand why ForeignPtr is defined the way it
is. It all seems rather complicated and redundant. I was thinking we might
want to switch to something simpler and more explicit, like this:
data ForeignPtr a = ForeignPtr {
fptr :: !(Ptr a) -- What we point to
froot
