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

Carter Schonwald carter.schonwald at gmail.com
Fri Oct 26 04:04:46 UTC 2018


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


More information about the Libraries mailing list