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

[Bertram Felgenhauer]

Daniel Cartwright wrote:
> There is no operational difference when using `Ptr a` vs `Addr` in such a
> case. The problem lies in the type variable `a`. Types are here to guide us
> - if I use `Ptr Word8`, and this Ptr is not a Ptr to Word8, there is not
> much enforcing this. In such cases, the type annotation is untruthful.

This is an argument against using a fully polymorphic `Ptr a` value as
an abstract pointer, but I don't see anything wrong with using `Ptr ()`
values or fully polymorphic `Ptr a` function arguments for that purpose.
With any such low-level code, you have to trust the programmer to get
things right anyway; replacing `Ptr ()` values by `Addr` values isn't
going to make a big difference.

> We
> would like it more often than not to be truthful. Yes, in the underlying C,
> there exists suboptimal typing, but that is why we are not writing in C,
> and instead lifting the code to Haskell.

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. And of course there is a risk of breaking existing code as
existing API is changed to use the new type. (The term "user-facing" has
popped up in this thread -- what does that mean in the case of such a
low-level API?)

Cheers,

Bertram