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

[Daniel Cartwright]

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