<div dir="ltr">Zemlya, I think you dropped this.<div><br></div><div>[1] <a href="https://hackage.haskell.org/package/base-4.10.0.0/docs/System-Mem-StableName.html">https://hackage.haskell.org/package/base-4.10.0.0/docs/System-Mem-StableName.html</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 8:03 PM, Zemyla <span dir="ltr"><<a href="mailto:zemyla@gmail.com" target="_blank">zemyla@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In that case, you probably want to use StableNames [1], which are<br>
unique and persistent even across GCs, and give you something you can<br>
use for a hash table.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Nov 23, 2017 at 6:48 AM, Michael Walker <<a href="mailto:mike@barrucadu.co.uk">mike@barrucadu.co.uk</a>> wrote:<br>
> Thanks for the feedback, all.<br>
><br>
> For some more context, I have a concurrency testing library[1], which<br>
> uses an algorithm called DPOR to reduce the space of possible<br>
> schedules it needs to explore.  There's an algorithm called MCR which<br>
> has the potential to reduce this space significantly further.  One of<br>
> the differences in MCR is taking into account reference equality of<br>
> values written to shared mutable variables.<br>
><br>
> I can't just use Eq because (a) putMVar/etc doesn't have an Eq<br>
> constraint in the type, and (b) that would change strictness.  So I<br>
> looked to reallyUnsafePtrEquality# as a possible solution.  In this<br>
> setting, false negatives are fine.  If the algorithm thinks two equal<br>
> values are distinct, then it doesn't run as fast as it could<br>
> potentially do, but should still outperform DPOR due to its other<br>
> improvements.  But false positives are not fine, and lead to<br>
> unsoundness.<br>
><br>
> An alternative is just using "\_ _ -> False", but if<br>
> reallyUnsafePtrEquality# will sometimes identify two equal things<br>
> without false positives, then it's effectively a free performance<br>
> boost in the cases where it happens to work.<br>
><br>
>> - Extending the previous scenario, if purity is violated in the<br>
>>   evaluation of the initially shared thunk, then x and y may become<br>
>>   distinct values later on.<br>
><br>
> Fortunately, I don't need to worry about impure actions leading to a<br>
> shared thunk evaluating to different things in different places, as<br>
> any nondeterminism beyond scheduler nondeterminism and relaxed memory<br>
> is already explicitly out of scope.<br>
><br>
> [1] <a href="http://hackage.haskell.org/package/dejafu" rel="noreferrer" target="_blank">http://hackage.haskell.org/<wbr>package/dejafu</a><br>
><br>
> --<br>
> Michael Walker (<a href="http://www.barrucadu.co.uk" rel="noreferrer" target="_blank">http://www.barrucadu.co.uk</a>)<br>
> ______________________________<wbr>_________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</div></div></blockquote></div><br></div>