<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Am Do., 1. Nov. 2018 um 01:22 Uhr schrieb Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>[...] 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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>