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

Daniel Cartwright chessai1996 at gmail.com
Fri Oct 26 17:42:34 UTC 2018


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>


More information about the Libraries mailing list