<div><div dir="auto">This example seems more a discussion about how the ghc-compact lib could benefit from better docs. </div></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 11:48 AM Andrew Martin <<a href="mailto:andrew.thaddeus@gmail.com">andrew.thaddeus@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">Look at the definition of SerializedCompact (in ghc-compact):<div><br></div><div>    data SerializedCompact a = SerializedCompact<br>      { serializedCompactBlockList :: [(Ptr a, Word)]<br>      , serializedCompactRoot :: Ptr a<br>      }<div><br class="m_-7109645444182420112gmail-Apple-interchange-newline"></div></div><div>The type variables on those Ptrs are a lie. The SerializedCompact needs that phantom type variable to keep track of what type of object in a compact region is represented by these blocks. But, the types of its two fields are extremely misleading. When I first saw this type, I was led to believe that I could call `peek` on the `serializedCompactRoot` field and get a value of type `a`. You cannot actually do that since it isn't actually a pointer to a value of that type. More correct would be:</div><div><br class="m_-7109645444182420112gmail-Apple-interchange-newline">    data SerializedCompact a = SerializedCompact<br>      { serializedCompactBlockList :: [(Addr, Word)]<br>      , serializedCompactRoot :: Addr<br>      }<br></div><div><br></div><div>This better documents what's actually going on here. We don't have a bunch of pointers to `a` values in a list. We value memory addresses that refer to arbitrary fragments of an object on the heap.</div><div><br></div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 11:32 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">Daniel : at this point you’re not show casing examples of why Address leads to better code than Pointer a</div></div><div dir="auto"><br></div><div dir="auto">A good library proposal makes code *better* in an unambiguous way.  As I mentioned yesterday , that’s been lacking here.  Or any improvements are ones sven , myself and others don’t see. :)</div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 10:41 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 dir="ltr">Am Di., 30. Okt. 2018 um 15:18 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">> 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></blockquote><div><br></div><div>Nope, not at all: Using a free type variable like "a" in such a situation is *the* common idiom to specify that the function doesn't care about the type, just like "length" doesn't care about the type of the elements. If you don't like that idiom, fine, but it has been officially enshrined in the standard and people are using it for decades (well, almost) without any problems, at least I haven't heard of them.</div><div><br></div><div>What would using Addr buy us? Addr is non-standard, and you would have to use some cast from a Ptr somehow (the world outside GHC's innards is using Ptr, not Addr). This would buy you exactly zero safety or clarity, and it would only introduce API friction.</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><div class="m_-7109645444182420112m_-7451498459826351161m_-2951098768613090453m_-1026956461681864337gmail-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><br></div></div><div class="m_-7109645444182420112m_-7451498459826351161m_-2951098768613090453m_-1026956461681864337gmail-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></blockquote><div>Nope again, see above.</div><div><br></div><div>I still fail to see what problem this whole proposal is actually trying to solve...</div></div></div>
</blockquote></div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________</blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-7109645444182420112gmail_signature" data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>
</blockquote></div></div>