<div dir="ltr">*only use i'm aware of<div><br></div><div>and its a pretty gross one.</div><div><br></div><div>are there any ACTUAL uses of Addr?  (granted, having a lifted / data'd version of unlifted types is general a useful thing)</div><div><br></div><div>Ptr Void having the byte address oriented interface for indexing arithmetic sounds good to me</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 27, 2018 at 9:56 AM 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><div dir="auto">Addr only exists within the primitive package.  And it only seems to be used in one spot in all of the vector package. And it’s a very weird spot that I honestly  may wanna redesign/see about changing  given how strange it is.  Especially since it may be one of those things where the current code needs some benchmarks </div><div dir="auto"><br></div><div dir="auto"><div><a href="https://github.com/haskell/vector/blob/master/Data/Vector/Storable/Mutable.hs#L164-L205" target="_blank">https://github.com/haskell/vector/blob/master/Data/Vector/Storable/Mutable.hs#L164-L205</a></div><br></div><div dir="auto"><br></div><div dir="auto">It’s the only instance in all of vector </div><div dir="auto"><br></div><div dir="auto"><br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 27, 2018 at 6:05 AM 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 Sa., 27. Okt. 2018 um 11:07 Uhr schrieb Bertram Felgenhauer via Libraries <<a href="mailto:libraries@haskell.org" target="_blank">libraries@haskell.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] We should also discuss the cost associated with mixing two functionally<br>
equivalent types in the same library, which will make the API less<br>
predictable, are likely to result in duplication in the APIs for Ptr and<br>
Addr, and will lead to more explicit type conversions with little<br>
benefit. [...]</blockquote><div><br></div><div>The more I think about it, the more serious I am about my "180 degree" proposal: Nuke Addr completely in favor of "Ptr a"/"Ptr ()". What can Addr do what a "Ptr a"/"Ptr ()" can't? Off the top of my head I would say "nothing". In most other circumstances we like generalizations, why not here? Having Addr just gives us a bigger API surface and is probably used mostly within GHC and its closely tied packages, not really "in the wild".</div><div><br></div><div>If "Ptr a" or "Ptr ()" or "Ptr Void" is the right thing to use in a specific place is always a tradeoff between ease of use, being explicit, readability, and perhaps what a corresponding C library uses. Type safety, as much as we like it, is just wishful thinking at that level, there's always castPtr (and of course the FunPtr counterparts).</div></div></div>
_______________________________________________<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></div>
</blockquote></div>