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

Fri Oct 26 15:00:55 UTC 2018

Also, where in base should Addr go?

On Fri, Oct 26, 2018 at 10:15 AM Daniel Cartwright <chessai1996 at gmail.com>
wrote:

> I would, yeah. Should the next version of `primitive` just re-export
> `Addr` from base in `Data.Primitive.Addr`?
>
> On Fri, Oct 26, 2018 at 10:14 AM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Daniel or David, would either of you be interested/willing to do the
>> legwork on this patch wise (subject to sanity checking whats the impact
>> surface area?)
>>
>> On Fri, Oct 26, 2018 at 12:04 AM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Cool. What apis in base should move to use Addr from fake pointer ?
>>> Cause just adding it in isolation seems lame!
>>>
>>> I guess I’m just trying to say “what would the impact on base, if every
>>> fake Ptr was moved to be Addr?” Because it’s not something which should be
>>> done by halves.
>>>
>>> 1) what apis would be changed?
>>>
>>> 2) what internal things would be changed albeit not Api visible
>>>
>>> 3). Address arithmetic for Addr is very different from addres arithmetic
>>> on larger than word8 size storable values, is there anything which would
>>> move representations where the change to byte indexed would change the
>>> calculations ?
>>>
>>>
>>> If we can layout what the impact / scope of changes needed for these and
>>> other considerations, I guess I’d be all for it. Assuming there’s the
>>> corresponding interest in executing changes. (I just have this worry in my
>>> head that it might be one of those icebergs.. like the split base effort )
>>>
>>>
>>>
>>> On Thu, Oct 25, 2018 at 11:33 PM David Feuer <david.feuer at gmail.com>
>>> wrote:
>>>
>>>> On Thu, Oct 25, 2018, 11:28 PM Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> Pretending we’re talking about this with storable as our example
>>>>> semantics :
>>>>>
>>>>> Ptr Void
>>>>> Corresponds to a memory address you don’t want to read or write to.
>>>>>
>>>>
>>>> This is not so easy to think about (there's not much utility in such a
>>>> type). Perhaps Ptr Void is a reasonable type for pointers known to be null
>>>> or outside the address space, but I'm not sure.
>>>>
>>>>
>>>>> Ptr () corresponds to a memory location that’s pretty boring to read /
>>>>> write to
>>>>>
>>>>
>>>> Yes! In other words, it's *not* what people should be using for a
>>>> pointer to an arbitrary non-Haskell address. That's precisely what Addr is
>>>> for.
>>>>
>>>>
>>>>> On Thu, Oct 25, 2018 at 11:22 PM Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> ... when is a valid pointer not going to point at byte addressable
>>>>>> memory on memory architectures ghc can support or target?
>>>>>>
>>>>>> On Thu, Oct 25, 2018 at 8:27 PM Daniel Cartwright <
>>>>>> chessai1996 at gmail.com> wrote:
>>>>>>
>>>>>>> Now, one could argue that `Ptr ()` isn't a lie, it sort of reads
>>>>>>> like C's void pointer. But surely something like `Ptr Word8` is a lie, when
>>>>>>> it is not actually a Ptr to Word8 values.
>>>>>>>
>>>>>>> On Thu, Oct 25, 2018 at 8:11 PM Daniel Cartwright <
>>>>>>> chessai1996 at gmail.com> wrote:
>>>>>>>
>>>>>>>> yes, only the type and its instances should be moved as far as i'm
>>>>>>>> aware.
>>>>>>>>
>>>>>>>> Also, it's more than just base.
>>>>>>>>
>>>>>>>> this Ptr is a lie:
>>>>>>>> https://hackage.haskell.org/package/ghc-compact-0.1.0.0/docs/GHC-Compact-Serialized.html#t:SerializedCompact
>>>>>>>> these Ptrs are lies:
>>>>>>>> https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-IO-Handle.html
>>>>>>>> in GHC.Stats, the foreign import "getRTSStats" has `Ptr () -> IO
>>>>>>>> ()`, this Ptr () is also a lie
>>>>>>>>
>>>>>>>> These are just off the top of my head, there are more
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 25, 2018 at 6:46 PM Carter Schonwald <
>>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> hrmm, what are the pieces of base that are using Ptr when they
>>>>>>>>> really should be using Addr? This would help me understand what would be
>>>>>>>>> made better in base :)
>>>>>>>>>
>>>>>>>>> On Thu, Oct 25, 2018 at 6:19 PM David Feuer <david.feuer at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> We shouldn't really need to move anything into base except Addr
>>>>>>>>>> and its base instances.
>>>>>>>>>>
>>>>>>>>>> On Oct 25, 2018 5:59 PM, "Carter Schonwald" <
>>>>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Indeed.  The monad transformer instances for primmonad need to
>>>>>>>>>> live in primmonad OR transformers to avoid orphans.
>>>>>>>>>>
>>>>>>>>>> Either way, unless transformers moves into base (unlikely), no
>>>>>>>>>> way anything using prim monad will.
>>>>>>>>>>
>>>>>>>>>> On Thu, Oct 25, 2018 at 3:34 PM Andrew Martin <
>>>>>>>>>> andrew.thaddeus at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I like the idea of moving the type Addr into base. But we cannot
>>>>>>>>>>> move the entire module since it has functions that talk about PrimMonad,
>>>>>>>>>>> and we definitely don't want to move that into base.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 25, 2018 at 11:25 AM Daniel Cartwright <
>>>>>>>>>>> chessai1996 at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Motivation: There are a lot of places in base where 'Ptr a' is
>>>>>>>>>>>> used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'.
>>>>>>>>>>>> The problem lies in the fact that many of these uses of 'Ptr a' are lying;
>>>>>>>>>>>> the 'a' value is meaningless. Authors of functions therein have used things
>>>>>>>>>>>> like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they
>>>>>>>>>>>> say they mean - they're just Addr. There are probably other motivations for
>>>>>>>>>>>> this that I can't think of off the top of my head right now.
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Libraries mailing list
>>>>>>>>>> Libraries at haskell.org
>>>>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>> 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/20181026/08c9d74f/attachment.html>