Re: ForeignPtr representation

2018-09-06 Thread David Feuer
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 wrote

Re: ForeignPtr representation

2018-09-06 Thread Simon Marlow
Wouldn't this mean that unpacking a ForeignPtr is one word longer than it is now? That would have a big impact on ByteString. What do you think is redundant in the current representation? Cheers Simon On Wed, 5 Sep 2018 at 00:23, David Feuer wrote: > I'm trying, and failing, to understand why