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

[Carter Schonwald]

hrmm, it looks like those aren't exposed directly to the HS layer because
of the necessary compiler time static alignment requirements for that in
code gen,


On Fri, Oct 26, 2018 at 2:13 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> yeah, lets do that, so roughly very little impact but easy opt in.
>
>  Is the design  code strawman  in https://phabricator.haskell.org/D5268
> acceptable?
>
> @David Feuer <david.feuer at gmail.com>  could you help me dig out where in
> ghc / base / ghc-prims we expose the memmove/memcopy/memset intrinsics? I
> can only seem to find the c ffi call ones,
> but I know ghc itself can compile that more smartly? i started but then i
> got lost, seems like everywhere in base its just a bespoked c ffi binding
> introduced locally ..
>
>
>
> On Fri, Oct 26, 2018 at 2:02 PM David Feuer <david.feuer at gmail.com> wrote:
>
>> The arithmetic parts are pretty obvious (indeed, it might be nice to add
>> some more arithmetic primops to treat Addr# as a uintptr_t). The rest are
>> much less obvious; it may make more sense to convert an Addr to a Ptr
>> before performing any dereferencing operations.
>>
>> On Fri, Oct 26, 2018, 1:55 PM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>>
>>> What api? It’s not obvious, could you spell out what you have in mind.
>>> Relative to the phab straw man?
>>>
>>> On Fri, Oct 26, 2018 at 1:42 PM Daniel Cartwright <chessai1996 at gmail.com>
>>> wrote:
>>>
>>>> there was never any hint at helping primitive, i'm not sure where you
>>>> got that from. also, the primary motivation was to avoid using 'Ptr a',
>>>> where 'a' is a lie. not only that, but base seems a natural home for
>>>> 'Addr', and people can avoid incurring a dep on primitive when they just
>>>> need 'Addr'.
>>>>
>>>> 'super useful' was never the goal - only correctness and convenience.
>>>>
>>>> Yeah, i agree that Storable should not be touched.
>>>>
>>>> On Fri, Oct 26, 2018 at 1:36 PM Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> your perspective here is a good one
>>>>>
>>>>> 1) i absolutely agree, nothing should touch storable, whatesoever,
>>>>>
>>>>> 2) the baseline proposal is to add an Addr to Base (essentially Ptr
>>>>> ()), which would be a crippled sibling of how its exposed in Data.Primitive
>>>>> I guess?
>>>>>
>>>>> 3) as a litmus for "what would this acomplish/support", i was asking
>>>>> "how would this get used/help base be nicer "? If
>>>>>
>>>>> anyways: i did a strawman of what Addr ripped out of
>>>>> Data.Primitive.Addr and into base would look like, and it doesn't look
>>>>> especially compelling / nicer than Ptr shenanigans. Especially since to be
>>>>> useful in base it would have to have a bunch of IO / ST specific operations
>>>>> that have the option perhaps of  using Storable to read /write at
>>>>> locations. At which point I still need to have the same API surface area
>>>>> again in Primitive,
>>>>>
>>>>> see https://phabricator.haskell.org/D5268 for the bare bones stuff
>>>>> (doesn't type check)
>>>>>
>>>>> the api i could expose there in base does not reduce the
>>>>> implementation surface area needed for Primitve...
>>>>>
>>>>> i'm open to being convinced otherwise, but with Sven's perspective
>>>>> weighed in,
>>>>> 1) i dont see it being super useful within base/ghc apis, as they
>>>>> exist today
>>>>> 2) it doesn't reduce implementation surface area burden in the
>>>>> Primitive package.
>>>>>
>>>>> so at this point im' weakly against the addition. more work, no clear
>>>>> reward for me :)
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 26, 2018 at 1:26 PM Sven Panne <svenpanne at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Am Fr., 26. Okt. 2018 um 06:05 Uhr schrieb Carter Schonwald <
>>>>>> carter.schonwald at gmail.com>:
>>>>>>
>>>>>>> [...] 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) [...]
>>>>>>>
>>>>>>> 2) [...]
>>>>>>>
>>>>>>> 3). [...]
>>>>>>>
>>>>>>
>>>>>> The most important question is missing from this list: What are the
>>>>>> benefits of touching such a crucial part of our API ecosystem? There should
>>>>>> better be extremely good reasons, otherwise lots of annoying work and
>>>>>> incompatibility is generated for nothing. Reading through this thread, I
>>>>>> haven't seen a good motivation for touching Storable/Ptr and friends.
>>>>>> Perhaps I have misunderstood what the actual proposal is, initially I
>>>>>> thought it is just replacing various "Ptr foo" with Addr only within GHC
>>>>>> itself. That's fine, but the scope seems to have broadened.
>>>>>>
>>>>>> Just a historical remark: Addr# is a GHCism, and so was Addr. At the
>>>>>> time the FFI came up, Ptr was intended to be the portable type. So yes,
>>>>>> "Ptr a" and "Ptr ()" are basically just Addr (modulo casts), but
>>>>>> intentionally so.
>>>>>>
>>>>> _______________________________________________
>>>>
>>>>
>>>>> 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/0fe839e3/attachment.html>