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

[Carter Schonwald]

Anyways. This proposal is dead.

Changing this internal stuff from Ptr to Addr doesn’t make an argument that
the code is better for it.  That has not be made.

Saying ptr a is a lie is about as informative as saying virtual memory is a
lie. Or the cpu caches are a lie.

Evidence works.  Saying something is a lie doesn’t.

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

> 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/f26b5b80/attachment.html>