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

[Gábor Lehel]

Compatibility issues aside, is there any reason newtypes aren't a good
solution here? You could get away with just one:

{-# LANGUAGE FlexibleInstances #-}

newtype FasterInsecureHashing a = FIH { unFIH :: a }

instance Hashable Int where
    hashWithSalt = ...stuff...

instance Hashable (FasterInsecureHashing Int) where
    hash = unFIH

instance Hashable ByteString where
    hashWithSalt = ...SipHash...

instance Hashable (FasterInsecureHashing ByteString) where
    hashWithSalt = ...CityHash...


On Tue, Mar 19, 2013 at 5:43 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Tue, Mar 19, 2013 at 9:19 AM, Thomas Schilling <nominolo at googlemail.com
> > wrote:
>
>> Oh, I just realised that this proposal is to include the older version
>> of hashable.  In principle, I'm not against that, but I do wonder what
>> the upgrade path is.  I don't think the performance problems can be
>> fixed in general -- that's just the price of security.  So it becomes
>> critical what the upgrade path looks like.  Do users get a slowdown of
>> 2x by default and then have to manually make it faster again if
>> something is not security sensitive?  Do users have to explicitly opt
>> in for security (a bad default, IMO)?  Do we have any idea how that
>> switch may affect the API?
>
>
> From an API standpoints, users of unordered-containers will be unaffected
> by any changes to hashable and people who write Hashable instances are
> unlikely to be affected either, as long as they write their instances in
> terms of hashWithSalt.
>
> From a performance standpoint, it depends on what we decide to make the
> default behavior of hashable be and for what types (e.g. we could use
> SIpHash for string types but a simple hash for Int-like types). This is the
> issue that's not already settled and the reason I'm holding hashable back
> to 1.1 for the platform. I'm leaning towards fast by-default as hashing is
> just one of many security issues web frameworks already consciously have to
> deal with. It's also an issue which have many alternative fixes, which
> don't require a stronger hash function.
>
> -- Johan
>
>
>


-- 
Your ship was destroyed in a monadic eruption.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130320/0fafc0b3/attachment.htm>