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

Tue Oct 30 16:35:58 UTC 2018

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