<div dir="ltr">Also, just to be clear, no one is talking about changing Storable, that seems terrible at this point. Your argument still makes sense to make outside of the context of wanting to change Storable, i just want to make sure it's reiterated that this is not being suggested.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 10:18 AM Daniel Cartwright <<a href="mailto:chessai1996@gmail.com">chessai1996@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> hPutBuf doesn't care about what stuff has been written into the given buffer, it just cares about its start and its size.<div>Seems like a good use for Addr?</div><div><div class="m_4053282226331519035gmail-gs" style="margin:0px;padding:0px 0px 20px;width:893px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><br></div></div><div class="m_4053282226331519035gmail-gs" style="margin:0px;padding:0px 0px 20px;width:893px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium">> <span style="font-family:Arial,Helvetica,sans-serif;font-size:small">If you have a pointer pointing to something and shift that pointer by some bytes, you are probably pointing to something completely different, so of course "b" and "a" have nothing to do with each other. So peekByteOff intentionally ignores "b".</span></div><div class="m_4053282226331519035gmail-gs" style="margin:0px;padding:0px 0px 20px;width:893px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small">This also seems like a good use for Addr?</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 10:10 AM Sven Panne <<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I am not sure if everybody fully comprehends what Storable is all about: It is meant as the lowest-level building block in an Addr-free world (remember: Addr is a GHCism and is *not* mentioned anywhere in the report) to put a few well-defined simple Haskell types into memory or read them from there. Its explicit non-goals are:</div><div><br></div><div>   * Achieve 100% type safety. In the presence of raw memory access, castPtr, C calls etc. this would be a total illusion. Forcing API users to sprinkle tons of castPtr at every possible place over their code wouldn't improve safety at all, it would only hurt readability.</div><div><br></div><div>   * Handle more complicated sum/product types. How would you do this? Respect your native ABI (i.e. automatically handle padding/alignment)? Tightly packed? Or even handle a foreign ABI? Your own ABI? Some funny encoding like OpenGL's packed data types? Etc. etc. You can build all of those things in a layer above Storable, probably introducing other type classes or some marshaling DSLs.</div><div><br></div><div>   * Portability of the written values. This is more in the realm of serialization libraries.</div><div><br></div><div>More concretely:</div><div><br></div><div dir="ltr">Am Di., 30. Okt. 2018 um 14:34 Uhr schrieb Daniel Cartwright <<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>[19:26:50] <chessai_> hPutBuf :: Handle -> Ptr a -> Int -> IO () [...]</div></div></div></blockquote><div><br></div><div>The signature for this is actually perfect: hPutBuf doesn't care about what stuff has been written into the given buffer, it just cares about its start and its size. Forcing castPtr Kung Fu here wouldn't buy you anything: The buffer will probably contain a wild mix of Haskell values or even no Haskell values at all, but that doesn't matter. Whatever you pass as "a" or whatever you cast from/to is probably a lie from the typing perspective. At this level this is no problem at all.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>[19:30:02] <chessai_> peekByteOff :: Ptr b -> Int -> IO a<br></div><div>[19:30:09] <chessai_> peekByteOff :: Addr -> Int -> IO a</div><div>[19:30:26] <chessai_> what is 'b' doing there? it's not used in any meaningful way by peekByteOff [...]</div></div></div></blockquote><div><br></div><div>If you have a pointer pointing to something and shift that pointer by some bytes, you are probably pointing to something completely different, so of course "b" and "a" have nothing to do with each other. So peekByteOff intentionally ignores "b".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>[19:32:22] <carter> pokeElemOff :: Ptr a -> Int -> a -> IO () --- way better than peak  [...]<br></div></div></div></blockquote><div><br></div><div>Yes, because this is intended to be used for *arrays* of values of the same type. Note "Elem" vs. "Byte".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div></div><div>[19:33:12] <carter> hvr: lets add safePeekByteOff :: Ptr a -> Int -> IO a ? [...]<br></div></div></div></blockquote><div><br></div><div>This signature doesn't make sense, see above: Shifting a pointer by an arbitrary amount of bytes will probably change the type of what you're pointing to. If you shift by units of the underlying type, well, that's peekElemOff.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div></div><div>[19:35:31] <chessai_> carter: i am glad we agree on the smell<br></div></div></div></blockquote><div><br></div><div>I don't have the full chat log, but I think I don't even agree on the smell, at least not at the places I've seen... :-) </div><div><br></div><div><br></div></div></div>
</blockquote></div>
</blockquote></div>