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

[Daniel Cartwright]

'Ptr Void' is not a pointer to a value of type 'Void'; there are no values
of type 'Void': this type is nonsensical.
'Ptr a' is not a pointer to a value of type a; what is 'a'?
'Ptr ()' could be a pointer to a value of type '()', and if so, then this
is a correct usage of 'Ptr'. If not, it is an incorrect usage of 'Ptr'.

On Sat, Oct 27, 2018 at 2:43 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> *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
>>>
>> _______________________________________________
> 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/20181029/ab5fd4b2/attachment.html>