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

[Carter Schonwald]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181026/1ce07860/attachment.html>