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

[Carter Schonwald]

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/29af0f2c/attachment-0001.html>