Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: stable ContentHashable for Hash{Map, Set}
Close tweag#215 `unordered-containers` structures, such as `HashMap` and `HashSet` uses `Hashable` `hash` function to maintain their internal structure. Hence the order of the items (when converting using `toList`, or `elems`, or just `traverse` or `fold`) depends on the version of `hashable` used. This results on a change of hash of theses structure when `hashable` library is updated. It is not possible to ensure that hash will never change for any type, because it relies on other instances, `Ord/Eq` for `containers` `Map` and `Set`, or even the implementation of `ContentHashable` itself. However `hashable` is known for its frequent changes when on the other hand, `Ord/Eq` instances are most of the time generated by `deriving` and are hence perfectly reproducible. This commit removes the dependency on the implicit order from `hashable` at the cost of an introduce `Ord` constraint on the keys of the `Hash{Map,Set}`. This is a tradeoff: - The user can still use `Hash{Map,Set}` based structure in their type for whatever reason they want (usually performance). - They will need to provide an `Ord` instance for `ContentHashable` - If an `Ord` instance already exists, this change will just bring stability. If the instance does not exist, user will now be aware of the problem. Note: this invalidate previous hash computed on `Hash{Map, Set}`.
- Loading branch information