<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 6:54 AM, wren ng thornton <span dir="ltr">&lt;<a href="mailto:wren@freegeek.org" target="_blank">wren@freegeek.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3/20/13 1:02 PM, Thomas Schilling wrote:&gt; To make this more precise the<br>
<div class="im">next version of hashable (say, 1.3)<br>
&gt; would include this:<br>
&gt;<br>
&gt;     newtype SipHashed a = SipHashed a<br>
&gt;<br>
&gt;     class SipHashable a where<br>
&gt;       sipHashWithSalt :: Int -&gt; a -&gt; Int<br>
&gt;<br>
&gt;     instance SipHashable a =&gt; Hashable (SipHashed a) where<br>
&gt;        hashWithSalt salt (SipHashed x) = sipHashWithSalt salt x<br>
&gt;<br>
&gt; Then all Hashable instances are taken from hashable-1.1.  All Hashable<br>
&gt; instances from hashable-1.2 are renamed to become instances of<br>
&gt; SipHashable.<br>
<br>
</div>That seems like a reasonable solution.<br>
<br>
I only ever use hashmaps explicitly for speed reasons and in applications<br>
that are not susceptible to DoS. The arguments about not wanting to<br>
introduce security issues due to some transitive dependency also hold for<br>
not wanting to introduce performance issues due to some transitive<br>
dependency. I respect all the folks working on web frameworks in Haskell,<br>
but there are also those of us who work on programs where compute time<br>
really is the number one concern (once an acceptable level of correctness<br>
and precision has been obtained); and when experiments are measured in<br>
days or weeks of cluster time, those &quot;little&quot; 1.3x and 1.5x slowdowns<br>
really hurt, let alone the 2.0x people&#39;ve mentioned with siphash.<br>
<br>
One concern with the above approach: is &quot;siphash&quot; a sufficiently generic<br>
name, or is it just one hashing method that happens to deflect this DoS<br>
issue? I haven&#39;t read the paper, so...<br></blockquote><div><br></div><div>There was also a complaint that the old hashable uses id as the hash function for Ints, while the new one always hashes them, also degrading performance. This might be a harder nut because `hash` itself was removed as a method of Hashable, but perhaps it could be added back(?), and then it could also be a case for the newtype. I can&#39;t remember what the motivation was for hashing them. In any case I&#39;d prefer a more generic name for the newtype, who knows if this kind of tradeoff might not be present elsewhere.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Live well,<br>
~wren<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Your ship was destroyed in a monadic eruption.
</div></div>