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

Carter Schonwald carter.schonwald at
Thu Nov 1 17:24:45 UTC 2018

Sven raises a good point :

Why can’t this all be workshopped out in user space ?  Plus it’s pretty
easy to ground proposals that might break stuff by ... trying to build

On Thu, Nov 1, 2018 at 8:08 AM Sven Panne <svenpanne at> wrote:

> Am Do., 1. Nov. 2018 um 01:22 Uhr schrieb Edward Kmett <ekmett at>:
>> [...] At some point in the future we can work out if it is worth it to
>> get the report fixed up by incorporating the Addr-based API as the default
>> and make the _other_ the legacy.
> Even though this thread is slowly approaching 100 mails, I still haven't
> heard a single convincing argument *why* anything should changed or *what*
> exactly is broken and *how* it effects API users. I very much disagree that
> there is anything to be "fixed" in that area. If you dislike the part of
> the Haskell Report, you are free to build your own APIs built on Addr,
> nothing is stopping you from doing that. Of course you will have some
> friction to the rest of the world which is using Ptr, but this is the price
> to pay when you deviate from standards.
> In a nutshell: Please show me e.g. some Wiki page with facts and real
> problems, not aesthetic opinions. It should be clear by now that we will
> never reach a consensus on that level, so in consequence the current status
> quo *must* win.
> Regarding the more fancy suggestions to sizeOf/alignment (proxies, some
> type Kung Fu): Remember that the FFI is part of the Haskell Report, so
> unless these things are in the report, too, there is no point discussing
> about such options. I'm not opposed to include such things in the report,
> far from it, but these things must go in first.
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list