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

[David Feuer]

Thankfully, Carter, you're not the sole arbiter of whether a library
proposal is dead. The discussion can surely continue without you.

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

> 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
>>>>
>>> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181030/f75c4fd5/attachment.html>