On 3/20/13 1:02 PM, Thomas Schilling wrote:> To make this more precise the next version of hashable (say, 1.3)
would include this:
newtype SipHashed a = SipHashed a
class SipHashable a where sipHashWithSalt :: Int -> a -> Int
instance SipHashable a => Hashable (SipHashed a) where hashWithSalt salt (SipHashed x) = sipHashWithSalt salt x
Then all Hashable instances are taken from hashable-1.1. All Hashable instances from hashable-1.2 are renamed to become instances of SipHashable.
That seems like a reasonable solution. I only ever use hashmaps explicitly for speed reasons and in applications that are not susceptible to DoS. The arguments about not wanting to introduce security issues due to some transitive dependency also hold for not wanting to introduce performance issues due to some transitive dependency. I respect all the folks working on web frameworks in Haskell, but there are also those of us who work on programs where compute time really is the number one concern (once an acceptable level of correctness and precision has been obtained); and when experiments are measured in days or weeks of cluster time, those "little" 1.3x and 1.5x slowdowns really hurt, let alone the 2.0x people've mentioned with siphash. One concern with the above approach: is "siphash" a sufficiently generic name, or is it just one hashing method that happens to deflect this DoS issue? I haven't read the paper, so... -- Live well, ~wren