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

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 https://github.com/haskell/vector/blob/master/Data/Vector/Storable/Mutable.h... It’s the only instance in all of vector On Sat, Oct 27, 2018 at 6:05 AM Sven Panne wrote:

Am Sa., 27. Okt. 2018 um 11:07 Uhr schrieb Bertram Felgenhauer via Libraries :

...

[...] We should also discuss the cost associated with mixing two functionally equivalent types in the same library, which will make the API less predictable, are likely to result in duplication in the APIs for Ptr and Addr, and will lead to more explicit type conversions with little benefit. [...]

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".

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). _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries