remove .Addr module from Primitive

[cartazio]

this is one of the task items that add up to making a version 0.7 release.

[cartazio]

this is mostly gated on getting a release of vector 0.12 and vector master to no long depend on that module.

[andrewthad]

I don't want this module to be removed. I use it in several projects I work on. Removing this would also break the symmetry of typed/untyped access to managed/unmanaged memory. What I mean is that:

• ByteArray provides an untyped interface to managed memory
• PrimArray provides a typed interface to managed memory
• Addr provides an untyped interface to unmanaged memory
• Ptr provides an untyped interface to unmanaged memory

Back in primitive-0.6.3, we just had two of these: ByteArray and Addr. Now we have the typed interfaces PrimArray and Ptr as well. All of these are useful dependending on how homogeneous the values stored at a memory location is. If we do remove Addr, then to avoid asymmetry in the APIs, we should remove ByteArray as well and do away with all the untyped interfaces. I don't want that though. I'd rather keep everything.

[cartazio]

hrm, this is an interesting symmetry argument, i'll think about it. (though I'll note that Symmetry based arguments dont really account for actual value / utility, comonads are symmetric to monads, but are a way less useful abstraction.)

as I look through https://packdeps.haskellers.com/reverse/primitive, theres many examples that use byte arrays, eg https://github.com/rrnewton/haskell-lockfree/blob/e9d0ebe085c0493fae4ac912e6e3340cb0069cb1/atomic-primops/Data/Atomics.hs#L50 , but i cant find any widely used code that uses Addr in a meaningful way/at all. ByteArray is never going way, there too much useful code that people use that builds on it, and we have the experience to show its a useful interface.

that said, I did the legwork to prepare a patch to remove usage of Data.Primitive.Address from the vector package, have a patch and I think makes the code clearer and less opaque. (vector provides a memset like batch initialization interface for all of the vector types, and 8/16/32/64 bit sized values does a clever roundtrip trick to use ghc/primitive's optimized memset via the Prim type class interface to provide efficient memset for any storable type where the rep has the same size as Word8/16/32/64. Interestingly this trick is safe even in the presence of Newtypes and prim/storable instances for the same type have distinct in memory representations!)

On Sun, Dec 2, 2018 at 9:02 PM Andrew Martin notifications@github.com wrote:

I don't want this module to be removed. I use it in several projects I work on. Removing this would also break the symmetry of typed/untyped access to managed/unmanaged memory. What I mean is that:

• ByteArray provides an untyped interface to managed memory
• PrimArray provides a typed interface to managed memory
• Addr provides an untyped interface to unmanaged memory
• Ptr provides an untyped interface to unmanaged memory

Back in primitive-0.6.3, we just had two of these: ByteArray and Addr. Now we have the typed interfaces PrimArray and Ptr as well. All of these are useful dependending on how homogeneous the values stored at a memory location is. If we do remove Addr, then to avoid asymmetry in the APIs, we should remove ByteArray as well and do away with all the untyped interfaces. I don't want that though. I'd rather keep everything.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/haskell/primitive/issues/219#issuecomment-443566691, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAQwin8enXvUrZGMoCvR9zKlPWWJ_avks5u1IYagaJpZM4Y9u-M .

[cartazio]

*vector does this trick for common cases of the Storable MVector class instances

[cartazio]

i genuinely want to understand/look at some code that uses Addr... and try to understand

1) how its being used

2) what an analogous ptr style api would be

3) how type inference user experience works out.

Ptr a style code makes it possible to have type inference between arguments to a function, AND/OR between inputs and outputs of a function. Addr never can do that. Its definitely true that some Ptr based haskell apis are terrible though. I just dont see any ways where Addr actually improves things ..

point being: I'm open to changing my stance, but that is contingent on showing me any examples that use Addr in a meaningful way.

i'm open to having as a deprecated module for a major version or something for Address even if i'm not convinced, but i would really love to be convinced. I like changing my mind, it means i learned something

[cartazio]

*try to understand for myself

[cartazio]

https://github.com/andrewthad/rotera/blob/7a5acca0e0b4c4e014500948607e065208713021/src/Rotera.hs seems to be one package, what are some of the others?

[cartazio]

heck, im open to experimenting on helping / trying to move some of your code to the Ptr style api this holiday season to understand how you use Addr if that move the needle one direction or the other wrt my understanding of how you use Addr and or your comfort thereof

[ekmett]

AFAICT this has been done.