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

[Carter Schonwald]

anyways, if you want to do a cleaned up sibling of
https://phabricator.haskell.org/D5268, i vote yes

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