<div><div dir="auto">That’s not a bad design pattern. I think eds struct Lib is sortah similar to that. </div></div><div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 3, 2018 at 2:56 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 Fri, 26 Oct 2018, Henning Thielemann wrote:<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>
Thinking about it ... these functions are intended for access of record <br>
fields. Then the following type signatures would have been better:<br>
<br>
peekField :: Ptr b -> Offset b a -> IO a<br>
pokeField :: Ptr b -> Offset b a -> a -> IO ()<br>
<br>
newtype Offset b a = Offset Int<br>
<br>
This way we had more type safety and no need for Addr or lying Ptr's.<br>
</blockquote></div></div>