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

[Carter Schonwald]

Daniel : at this point you’re not show casing examples of why Address leads
to better code than Pointer a

A good library proposal makes code *better* in an unambiguous way.  As I
mentioned yesterday , that’s been lacking here.  Or any improvements are
ones sven , myself and others don’t see. :)

On Tue, Oct 30, 2018 at 10:41 AM Sven Panne <svenpanne at gmail.com> wrote:

> Am Di., 30. Okt. 2018 um 15:18 Uhr schrieb Daniel Cartwright <
> chessai1996 at gmail.com>:
>
>> > hPutBuf doesn't care about what stuff has been written into the given
>> buffer, it just cares about its start and its size.
>> Seems like a good use for Addr?
>>
>
> Nope, not at all: Using a free type variable like "a" in such a situation
> is *the* common idiom to specify that the function doesn't care about the
> type, just like "length" doesn't care about the type of the elements. If
> you don't like that idiom, fine, but it has been officially enshrined in
> the standard and people are using it for decades (well, almost) without any
> problems, at least I haven't heard of them.
>
> What would using Addr buy us? Addr is non-standard, and you would have to
> use some cast from a Ptr somehow (the world outside GHC's innards is using
> Ptr, not Addr). This would buy you exactly zero safety or clarity, and it
> would only introduce API friction.
>
>
>> > If you have a pointer pointing to something and shift that pointer by
>> some bytes, you are probably pointing to something completely different, so
>> of course "b" and "a" have nothing to do with each other. So peekByteOff
>> intentionally ignores "b".
>> This also seems like a good use for Addr?
>>
> Nope again, see above.
>
> I still fail to see what problem this whole proposal is actually trying to
> solve...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181030/b6840f0c/attachment.html>