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

Tue Oct 30 16:45:16 UTC 2018

David:
Please don’t make this personal.

Either way you’re definitely correct that this is a discussion list to
inform clc decisions and or applicable library maintainers.

I’m speaking as a maintainer.of vector and primitive

On Tue, Oct 30, 2018 at 12:38 PM David Feuer <david.feuer at gmail.com> wrote:

> Private off-list discussions are not, were never, and will never be a part
> of the proposal process, and for good reasons. Mentioning them only makes
> you look like you're trying to use your connections to bypass the process.
> Please don't.
>
> On Tue, Oct 30, 2018, 12:36 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Repeating it’s a lie isn’t an argument.
>>
>> Writing code and comparing it is a way to make a case. I even put some up
>> on phabticator.  Then decided it’s actually not a useful piece of code.
>>
>> I’ve spoke with a number of folks privately and I’m arriculating the lack
>> of suport and clear case.
>>
>> I’m open to being wrong and that this proposal is great.  But changing a
>> type signature isn’t show casing what code is improved. It’s just a proof
>> that the change can be made.
>>
>> I need evidence.  As does everyone :)
>>
>> On Tue, Oct 30, 2018 at 12:25 PM David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> 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/c6b20ec4/attachment.html>