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

[Gábor Lehel]

On Thu, Mar 21, 2013 at 6:54 AM, wren ng thornton <wren at freegeek.org> wrote:

> 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...
>

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't remember what the motivation
was for hashing them. In any case I'd prefer a more generic name for the
newtype, who knows if this kind of tradeoff might not be present elsewhere.


>
> --
> Live well,
> ~wren
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
Your ship was destroyed in a monadic eruption.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20130321/ec219ace/attachment.htm>