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

Fri Oct 26 14:15:05 UTC 2018

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