<div dir="ltr"><div dir="ltr">your perspective here is a good one<div><br></div><div>1) i absolutely agree, nothing should touch storable, whatesoever,</div><div><br></div><div>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? </div><div><br></div><div>3) as a litmus for "what would this acomplish/support", i was asking "how would this get used/help base be nicer "? If </div><div><br></div><div>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, </div><div><br></div><div>see <a href="https://phabricator.haskell.org/D5268">https://phabricator.haskell.org/D5268</a> for the bare bones stuff (doesn't type check)</div><div><br></div><div>the api i could expose there in base does not reduce the implementation surface area needed for Primitve...</div><div><br></div><div>i'm open to being convinced otherwise, but with Sven's perspective weighed in, </div><div>1) i dont see it being super useful within base/ghc apis, as they exist today</div><div>2) it doesn't reduce implementation surface area burden in the Primitive package.</div><div><br></div><div>so at this point im' weakly against the addition. more work, no clear reward for me :) </div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 1:26 PM Sven Panne <<a href="mailto:svenpanne@gmail.com">svenpanne@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Am Fr., 26. Okt. 2018 um 06:05 Uhr schrieb Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="auto">[...] 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. <br></div></div></div><div dir="auto"><br></div><div dir="auto">1) [...]</div><div dir="auto"><br></div><div dir="auto">2) [...]</div><div dir="auto"><br></div><div dir="auto">3). [...]</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>
</blockquote></div>