<div dir="ltr"><div dir="ltr">anyways, if you want to do a cleaned up sibling of <a href="https://phabricator.haskell.org/D5268">https://phabricator.haskell.org/D5268</a>, i vote yes</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 1:55 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@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><br></div><div><div dir="auto">What api? It’s not obvious, could you spell out what you have in mind. Relative to the phab straw man? </div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 1:42 PM Daniel Cartwright <<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@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">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'. <div><br></div><div>'super useful' was never the goal - only correctness and convenience.</div><div><br></div><div>Yeah, i agree that Storable should not be touched.</div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 1:36 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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" target="_blank">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></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________</blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>