<div dir="auto">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?</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018, 5:15 AM Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Thu, 25 Oct 2018, David Feuer wrote:<br>
<br>
> Ptr Word8 is not (just) a pointer to byte-addressable memory. It's <br>
> specifically a pointer to something representing an 8-bit unsigned <br>
> integer. If you use a Ptr Word8 for the address of a floating point <br>
> value, then you are *wrong* (or doing something very weird, anyway). To <br>
> quote the documentation,<br>
> <br>
> A value of type Ptr a represents a pointer to an object, or an array of <br>
> objects, which may be marshalled to or from Haskell values of type a.<br>
<br>
Interesting observations.<br>
<br>
There are the Storable methods<br>
<br>
peekByteOff :: Ptr b -> Int -> IO a<br>
pokeByteOff :: Ptr b -> Int -> a -> IO ()<br>
<br>
They ignore the target types of their pointers. Should be Addr, then, too?<br>
<br>
And if we are touching Storable class, how about passing Proxy's to sizeOf <br>
and alignment instead of undefined values? Maybe we should add new methods <br>
to Storable class with default implementations that redirect to the old <br>
methods.<br>
</blockquote></div>