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

[Carter Schonwald]

There’s no class constraint here, so I would instead assume I need to read
the paper / docs and source code for how heap objects are encoded here.
Changing the type to Addr vs Ptr a or Ptr void is a red herring /
irrelevant

On Tue, Oct 30, 2018 at 12:09 PM Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> This example seems more a discussion about how the ghc-compact lib could
> benefit from better docs.
>
> On Tue, Oct 30, 2018 at 11:48 AM Andrew Martin <andrew.thaddeus at gmail.com>
> wrote:
>
>> 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/f7ac3e85/attachment.html>