Adding `purescript-unordered-collections` to the `contrib` set of Purescript libraries

[janherich]

First of all, big thanks to you @fehrenbach, this implementation of Hash based collections is amazing, pleasure to work with and with very good performance.

My only issue is that compared to purescript-ordered-collections, this lib is not in contrib, which means that contrib libraries like purescript-profunctor-lenses can't depend on it (so my PR adding support for Hashable typeclass will be almost certainly declined).
I would love for this lib to become "first class citizen" in the purescript ecosystem, how could I help to make that happen ?
I see that there is a open PR for compiler derivation of Hashable, is that the main blocker, or something else ?

[fehrenbach]

Thanks, I'm glad you like it.

I think the best place to start would be to revive this issue: purescript/purescript-prelude#188
It looks like the feedback at the time was generally positive.

Open questions there were whether to newtype hashes or not and whether the class should be hashWithSalt or just hash. I now think the answers should be: no newtype (unwrapping and rewrapping is too painful), and put hashWithSalt in the class. I might just open a PR for that on the weekend.

I have no idea how badly the deriving PR has bitrotted. That would need some work. It also would need changing to use hashWithSalt.

As for putting this whole library in contrib. I wouldn't rule it out completely, but I'm not enthusiastic. (And I expect contrib maintainers might also not be enthusiastic. It's a lot of JS code.) More to the point, it doesn't really solve the dependency issue. Nearly everything should not depend on unordered-collections. Nearly everything already depends on prelude, so adding Hashable there really is the way to go.

[fehrenbach]

Oh, but is Hashable in prelude even enough for the profunctor stuff? janherich/purescript-profunctor-lenses@0158e27 this looks like no. You want instances for At and Index.
Is purescript still so strict about no orphan instances?
I'm not super happy to depend on productor-lenses just to provide these instances, but I'm not sure there's any other way.

[janherich]

@fehrenbach Correct -> I think that having Data.Hashable typeclass in Prelude is a great goal although it won't help in some cases like with profunctors (but it would in some other cases, like the issue I have with with the UUIDv4 lib).
For the profunctors, typeclass is indeed not enough and the most logical solution would be to include purescript-unordered-collections in contrib (probably as a second step, with Data.Hashable already in prelude).

I think it's completely reasonable to have both ordered/unordered collections in contrib -> if anything, unordered are less specific, more generic and probably better default in most cases (but maybe I'm biased coming from Clojure, where unordered hash maps/sets are default).