Proposal: Move primitive-Data.Primitive.Addr API into base

[Andrew Martin]

Look at the definition of SerializedCompact (in ghc-compact):

    data SerializedCompact a = SerializedCompact
      { serializedCompactBlockList :: [(Ptr a, Word)]
      , serializedCompactRoot :: Ptr a
      }

The type variables on those Ptrs are a lie. The SerializedCompact needs
that phantom type variable to keep track of what type of object in a
compact region is represented by these blocks. But, the types of its two
fields are extremely misleading. When I first saw this type, I was led to
believe that I could call `peek` on the `serializedCompactRoot` field and
get a value of type `a`. You cannot actually do that since it isn't
actually a pointer to a value of that type. More correct would be:

    data SerializedCompact a = SerializedCompact
      { serializedCompactBlockList :: [(Addr, Word)]
      , serializedCompactRoot :: Addr
      }

This better documents what's actually going on here. We don't have a bunch
of pointers to `a` values in a list. We value memory addresses that refer
to arbitrary fragments of an object on the heap.


On Tue, Oct 30, 2018 at 11:32 AM Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Daniel : at this point you’re not show casing examples of why Address
> leads to better code than Pointer a
>
> A good library proposal makes code *better* in an unambiguous way.  As I
> mentioned yesterday , that’s been lacking here.  Or any improvements are
> ones sven , myself and others don’t see. :)
>
> On Tue, Oct 30, 2018 at 10:41 AM Sven Panne <svenpanne at gmail.com> wrote:
>
>> Am Di., 30. Okt. 2018 um 15:18 Uhr schrieb Daniel Cartwright <
>> chessai1996 at gmail.com>:
>>
>>> > hPutBuf doesn't care about what stuff has been written into the given
>>> buffer, it just cares about its start and its size.
>>> Seems like a good use for Addr?
>>>
>>
>> Nope, not at all: Using a free type variable like "a" in such a situation
>> is *the* common idiom to specify that the function doesn't care about the
>> type, just like "length" doesn't care about the type of the elements. If
>> you don't like that idiom, fine, but it has been officially enshrined in
>> the standard and people are using it for decades (well, almost) without any
>> problems, at least I haven't heard of them.
>>
>> What would using Addr buy us? Addr is non-standard, and you would have to
>> use some cast from a Ptr somehow (the world outside GHC's innards is using
>> Ptr, not Addr). This would buy you exactly zero safety or clarity, and it
>> would only introduce API friction.
>>
>>
>>> > If you have a pointer pointing to something and shift that pointer by
>>> some bytes, you are probably pointing to something completely different, so
>>> of course "b" and "a" have nothing to do with each other. So peekByteOff
>>> intentionally ignores "b".
>>> This also seems like a good use for Addr?
>>>
>> Nope again, see above.
>>
>> I still fail to see what problem this whole proposal is actually trying
>> to solve...
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181030/64198cd8/attachment.html>