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

[Carter Schonwald]

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