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

wren ng thornton wren at
Fri Mar 22 05:09:49 CET 2013

On 3/21/13 4:30 PM, Roman Cheplyaka wrote:
> * Thomas Moertel <tom at> [2013-03-21 15:58:58-0400]
>> On Wed, Mar 20, 2013 at 5:05 PM, Johan Tibell
<johan.tibell at>wrote:
>>> The problem is that if the secure hashing makes HashMap as slow as Map,
>>> there's no point in having the former in the first place, as it only
>>> to provide speed.
>> I understand that HashMap exists to provide speed, but are we sure that
>> everyone who uses it for speed understands the security implications?
>> Regardless of whether speed-first or security-first is the default, users
>> of HashMap can be partitioned into two groups: those who knowingly choose
>> between speed and security, and those who do not. For the first group,
>> either default is safe because members of that group will have the
>> opportunity to choose the other option. But for the second group, only
>> security-first is safe: if it’s not the default, members of the second
>> group won’t have the option to choose it.
> Why not simply educate them by placing a prominent notice in the
> haddock?

+1. Whenever there's this split between knowing-choice and ignorance, my
preferred solution is always to educate people.

Sometimes there are cases where one side of the choice is obviously
superior, or where it's too difficult to explain what is at stake for the
choice. In these cases I'm a fan of preferring the "safe" choice, because
(a) it's obvious, or (b) education is too costly.

But that's not so clear for something like significant speed benefits
(which are crucial for some, and nice for all) vs defense against DoS
(which are crucial for some, but irrelevant to others). Given that both
benefits are crucial for some, either we should have no default ---for
fear of offending either side--- or we should ignore both of those parties
(since they are of approximately equal prominence), in which case things
fall back to nice-for-all vs irrelevant-to-others, which favors speed as
the default.

Thankfully, in Haskell we have enough polymorphism that it's feasible to
eschew a default choice, and it's also feasible to override whatever the
default is. That puts us in a much better place than most other languages
faced with this choice.

Live well,

More information about the Libraries mailing list