问题
I do not understand why Data.HashTable is using Data.Hashable , which has hashWithSalt as the (only/basic) method.
This does not fit with the natural optimization of computing the hash value once, and storing it in the object (natural, because Haskell objects are immutable).
If I want to use HashTables with that, then I'm forced to implement hashWithSalt.
(Going 1.2.0.* to 1.2.1.*, hashable re-introduced hash as a class method, but this does not help?)
The actual Table implementations don't seem to make use of hashWithSalt (HashTable.ST.Linear does not at all, HashTable.ST.Cuckoo uses two fixed salts only).
回答1:
As Carl notes in the comments, the move to the hashWithSalt method over just hash (as the original Hashable used) was to allow people to mitigate DOS attacks based on hash collisions. For a period, a different random default salt was generated on every run, even, using unsafePerformIO in the background. This lack of reproducibility turned out to be a huge problem, however, for people interested in e.g. persisting data structures across runs, getting reliable benchmarking numbers, etc.
So, the current approach is to provide the method, but tend to defer to a default salt that is fixed, and then add a warning to the documentation that this remains susceptible to various potential DOS attack vectors if used in a public-facing ways. (You can see for yourself in the documentation here: http://hackage.haskell.org/package/hashable-1.2.1.0/docs/Data-Hashable.html)
Because hash is its own class method, it is easy enough to implement an object with a "saltless" hash that is memoed with it, and furthermore, you can implement hashWithSalt as just xoring with the salt if you like. Or, as the comments note, you can implement hashWithSalt via a more legitimate method of hashing your generated/memoed hash.
来源：https://stackoverflow.com/questions/23844612/why-does-data-hashtable-use-hashing-with-salt-from-data-hashable