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

[Carter Schonwald]

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