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

Tue Oct 30 16:38:04 UTC 2018

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