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

[Sven Panne]

Am Sa., 27. Okt. 2018 um 11:07 Uhr schrieb Bertram Felgenhauer via
Libraries <libraries at haskell.org>:

> [...] 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181027/cf73a373/attachment.html>