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

Carter Schonwald carter.schonwald at gmail.com
Sat Oct 27 13:56:21 UTC 2018


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/732a55e0/attachment.html>


More information about the Libraries mailing list