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

[Conrad Parker]

On 22 March 2013 05:32, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Thu, Mar 21, 2013 at 2:26 PM, Isaac Dupree
> <ml at isaac.cedarswampstudios.org> wrote:
>>
>> Regarding hashWithSalt determinism:
>>
>> hashable 1.1:
>> "The general contract of hash is: * This integer need not remain
>> consistent from one execution of an application to another execution of the
>> same application. [...] The contract for hashWithSalt is the same as for
>> hash, with the additional requirement that any instance that defines
>> hashWithSalt must make use of the salt in its implementation." [1]
>>
>> hashable 1.2:
>> "The general contract of hashWithSalt is: * If a value is hashed using the
>> same salt during distinct runs of an application, the result must remain the
>> same. (This is necessary to make it possible to store hashes on persistent
>> media.) [...]"
>>
>> Which contract do we want?
>
>
> When I wrote the 1.1 contract I gave me lots of leeway to change the
> implementation in the future. The actual implementation was that the hash
> was always the same between run to run for a given architecture.
>
> I'm not terribly happy with the "This is necessary to make it possible to
> store hashes on persistent media." part of the 1.2 contract. I should
> probably not have let that go in. If you're persisting your hashes you
> should use a hash function that guarantees exactly which algorithm is used.
>
> I think the contract should be: the hash function is guaranteed to return
> the same hash code for a given value as long as the code is compiled with
> the same version of hashable, unless the user explicit turns on hash
> randomization (i.e. random seed read from /dev/urandom). I don't think we
> should make any guarantees that a new version of hashable won't change the
> hash function used.

It seems like there's two common uses for hashes:
  a) secure, one-way digests
  b) fast keys for balanced containers

It's easy to think of programs which would make use of both kinds of
hash for different things.

The existing API with the nice simple short-named "hash" function will
continue to:
  * annoy people who prefer one or the other, but read the docs and
find out they're not getting what they want
  * infuriate people who expect one or the other, but don't read the
docs then complain that Haskell is slow or insecure
  * burden people who would make use of either kind of hash
appropriately, but now need to read the docs or source to find out
what to do

I'd suggest to annoy everyone equally by deprecating the existing API
and introducing separately named functions like:

  secureHash
  insecureHash / fastHash

As it stands, anyone who cares about any of this has to pay attention
to the particular version of hashable they are using, which sounds
like a recipe for failure. This thread puts it perhaps around level 9
on:

http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html

Why not just throw it out and introduce a version 2.0 with an unambiguous API?

Conrad.