Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform

[wren ng thornton]

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