<div><div dir="auto">David: </div></div><div dir="auto">Please don’t make this personal. </div><div dir="auto"><br></div><div dir="auto">Either way you’re definitely correct that this is a discussion list to inform clc decisions and or applicable library maintainers. </div><div dir="auto"><br></div><div dir="auto">I’m speaking as a maintainer.of vector and primitive </div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 12:38 PM David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@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="auto">Private off-list discussions are not, were never, and will never be a part of the proposal process, and for good reasons. Mentioning them only makes you look like you're trying to use your connections to bypass the process. Please don't.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018, 12:36 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@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><div dir="auto">Repeating it’s a lie isn’t an argument. </div><div dir="auto"><br></div><div dir="auto">Writing code and comparing it is a way to make a case. I even put some up on phabticator. Then decided it’s actually not a useful piece of code. </div><div dir="auto"><br></div><div dir="auto">I’ve spoke with a number of folks privately and I’m arriculating the lack of suport and clear case. </div><div dir="auto"><br></div><div dir="auto">I’m open to being wrong and that this proposal is great. But changing a type signature isn’t show casing what code is improved. It’s just a proof that the change can be made. </div><div dir="auto"><br></div><div dir="auto">I need evidence. As does everyone :)</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 12:25 PM David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer" target="_blank">david.feuer@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="auto">Thankfully, Carter, you're not the sole arbiter of whether a library proposal is dead. The discussion can surely continue without you.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018, 12:22 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer" target="_blank">carter.schonwald@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><div dir="auto">Anyways. This proposal is dead. </div><div dir="auto"><br></div><div dir="auto">Changing this internal stuff from Ptr to Addr doesn’t make an argument that the code is better for it. That has not be made. </div><div dir="auto"><br></div><div dir="auto">Saying ptr a is a lie is about as informative as saying virtual memory is a lie. Or the cpu caches are a lie. </div><div dir="auto"><br></div><div dir="auto">Evidence works. Saying something is a lie doesn’t. </div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 12:11 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer noreferrer" target="_blank">carter.schonwald@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><div dir="auto">There’s no class constraint here, so I would instead assume I need to read the paper / docs and source code for how heap objects are encoded here. Changing the type to Addr vs Ptr a or Ptr void is a red herring / irrelevant </div></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 12:09 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer noreferrer" target="_blank">carter.schonwald@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><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" rel="noreferrer noreferrer" target="_blank">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_-2923532958065284167m_8264388091972950367m_-814850643474886607m_252296887330130601m_-7690423407301657872m_-6200428497607273131m_-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_-2923532958065284167m_8264388091972950367m_-814850643474886607m_252296887330130601m_-7690423407301657872m_-6200428497607273131m_-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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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_-2923532958065284167m_8264388091972950367m_-814850643474886607m_252296887330130601m_-7690423407301657872m_-6200428497607273131m_-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_-2923532958065284167m_8264388091972950367m_-814850643474886607m_252296887330130601m_-7690423407301657872m_-6200428497607273131m_-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" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer 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_-2923532958065284167m_8264388091972950367m_-814850643474886607m_252296887330130601m_-7690423407301657872m_-6200428497607273131m_-7109645444182420112gmail_signature" data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>