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

[Carter Schonwald]

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