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

[Carter Schonwald]

*only use i'm aware of

and its a pretty gross one.

are there any ACTUAL uses of Addr?  (granted, having a lifted / data'd
version of unlifted types is general a useful thing)

Ptr Void having the byte address oriented interface for indexing arithmetic
sounds good to me

On Sat, Oct 27, 2018 at 9:56 AM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Addr only exists within the primitive package.  And it only seems to be
> used in one spot in all of the vector package. And it’s a very weird spot
> that I honestly  may wanna redesign/see about changing  given how strange
> it is.  Especially since it may be one of those things where the current
> code needs some benchmarks
>
>
> https://github.com/haskell/vector/blob/master/Data/Vector/Storable/Mutable.hs#L164-L205
>
>
> It’s the only instance in all of vector
>
>
>
> On Sat, Oct 27, 2018 at 6:05 AM Sven Panne <svenpanne at gmail.com> wrote:
>
>> 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).
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181027/f8109c90/attachment.html>