core: add Hasher and HashableModule

[superlopuh]

These utils are planned to be used in xdsl-gui, but may well be useful outside of that project. The Hasher contains logic I've used a lot before, it seems to work well enough. In the future, we might want a more efficient way to compute equality/inequality for modules, but we might as well add a working helper class now and optimise later.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (8c3e32c) 89.44% compared to head (bf6ce43) 89.45%.
Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2210   +/-   ##
=======================================
  Coverage   89.44%   89.45%           
=======================================
  Files         319      323    +4     
  Lines       38684    38741   +57     
  Branches     5729     5734    +5     
=======================================
+ Hits        34601    34655   +54     
- Misses       3281     3286    +5     
+ Partials      802      800    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AntonLydike]

I feel that this is quite a convoluted way of implementing a __hash__.

What would be the downside of computing a key (tuple of operation names) and calling hash on that? I feel that this might result in much simpler code. (It would also introduce less new code that needs testing)

Furthermore, we should take into account that hashes of mutable objects may result in unexpected/broken behavior, I think having a clearer warning on the HashableModule class would be helpful in communicating the problems associated with that.

[superlopuh]

I feel like it's pretty standard, it lets users create a hash of complex objects without having all of the things that compose the hash in memory at a time, making it much more efficient than a hash of a tuple of ops. I also don't feel like it's that complicated, I guess that depends on how used to it the reader is. Swift's hash works like this, so I guess I'm used to it. I also didn't want to go just with xor since that drops the order of elements, but I guess few rewrites just reorder operations, so maybe that should be fine for the sake of hashing in the short term.

[math-fehr]

Nice!
I wouldn't use just a xor here, as it will have a lot of collisions (to be exact, if you have the same parity of every operation, then it will have the same hash, the order won't matter at all).
But that's something we can always fix later, so I'm fine with merging it now!

[AntonLydike]

I wouldn't use just a xor here, as it will have a lot of collisions (to be exact, if you have the same parity of every operation, then it will have the same hash, the order won't matter at all).

I totally agree, we can replace the xor with hash((self.hash, other_hash)) for it to fall back to a known good hash instead of rolling our own.

[superlopuh]

Good idea!