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

[Daniel Cartwright]

I'm only saying that 'Addr', its base-scoped instances, and the API of
'Data.Primitive.Addr' that is base-scoped should be added to base.
Eventually any non-user-facing functions that use 'Ptr LyingType' should be
switched from using 'Ptr' to 'Addr'. There's nothing more to my proposal as
far as action items.

As far as consequences, users may want to have access to 'Addr' without
needing 'primitive'. 'primitive' shouldn't really see any API change, as it
will just re-export whatever gets implemented in base for 'Addr'.

On Fri, Oct 26, 2018 at 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181026/4d25bbf3/attachment-0001.html>