The law of Prim is “whatever is best for vector ”, which is really about
making sure it’s easy to write soa and aos memory layouts representations
for vector. It has nothing to do with storable. Storable is for fixed size
c struct mappable values. That they do similar things api wise is a trick
rather than a connection.
Either way that’s orthogonal to Ptr and Adr.
On Fri, Oct 26, 2018 at 6:16 AM David Feuer
While we're in that realm, it would be nice to find a mechanism that will explain what we need for both Storable (stick something at an Addr address) and Primitive (stick something in a MutableByteArray). The current situation is rather annoying. Can the compiler help?
On Fri, Oct 26, 2018, 5:15 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Thu, 25 Oct 2018, David Feuer wrote:
Ptr Word8 is not (just) a pointer to byte-addressable memory. It's specifically a pointer to something representing an 8-bit unsigned integer. If you use a Ptr Word8 for the address of a floating point value, then you are *wrong* (or doing something very weird, anyway). To quote the documentation,
A value of type Ptr a represents a pointer to an object, or an array of objects, which may be marshalled to or from Haskell values of type a.
Interesting observations.
There are the Storable methods
peekByteOff :: Ptr b -> Int -> IO a pokeByteOff :: Ptr b -> Int -> a -> IO ()
They ignore the target types of their pointers. Should be Addr, then, too?
And if we are touching Storable class, how about passing Proxy's to sizeOf and alignment instead of undefined values? Maybe we should add new methods to Storable class with default implementations that redirect to the old methods.