Open bifunctor opened 3 years ago
Hi @bifunctor ,
Good point! Never really thought about it, but it might be convenient to make the ir
nodes hashable. One reason why they perhaps are not hashable is that they might be modified (in other words, they might not be immutable). For example the python list
is mutable, and hence not hashable. A tuple
on the other hand is immutable, and hence hashable. The IR nodes shoud probably be immutable, but I know that they are sometimes modified in place, for example in some optimization passes.
So in short: no specific reason, just never thought about it.
tl;dr: Its a good idea to implement __eq__
, and (maybe) an okay idea to implement __hash__
.
I believe that support should be added for __eq__
and __hash__
(or at very least __eq__
). As you said, hashing might be problematic in the case of mutability. A way to get around this would be to hash only some defining attributes. For example, Block
's name
and function
won't be changed (once function
is set that is). So Block
could be hashed as so:
class Block:
...
def __hash__(self):
assert self.function, "function should have been set"
return hash((self.name, self.function))
or if you wish to be able to compare blocks without having added them to functions:
class Block:
...
def __hash__(self):
return hash(self.name)
and so on.
Hello, I'm quite new to PPCI. While I was looking in
ir.py
, I was wondering why the nodes don't have__eq__
of__hash__
implemented in them. Is there a reason behine this? Maybe a way to get around it? Thanks!