pymc-devs
Reconsider using `unification` library for `PatternNodeRewriter`
Description
A quick simple implementation seems to be 8x faster, avoiding the whole multiple-dispatch approach.
Also it should give us more flexibility to unify with variadic/commutative patterns as explored in #1592
This would make our current dependency on unification/kanren completely optional (the latter should already be optional), reducing our default dependencies
In principle the unification stuff offers more power right? We're just not using it?
The unification library itself is not more powerful in ways that could ever be relevant for you. If you wanted to unify ops used in python nested sequences or classes, but we never would do that.
What's more powerful is kanren, which itself uses the unification/etuples library, but we're not really making use of this, and even if we were it wouldn't be incompatible with a more streamlined/hackable implementation of unification for the purposes of PatternNodeRewriter
Not against not using it, but I'm simply not in a good position to know if we're leaving value on the table by not leaning more into it vs going deeper into other options (like the new pattern system you hacked up)
The unification library itself doesn't have more depth to it. It's literally a python_structure_with_xs_in_it == python_structure_with_values_in_it -> give me the values that are in place of the xs.
It's slow because it's flexible, the structure may be a tuple, or a list, or the values of a dict or the attributes of a class (or nested combinations of these), using multipledispatch for handling these cases. It also tries to avoid recursion issues, which we don't care about since our patterns are never deep.
Since we only ever need shallow tuples, we're paying extra cost. And if we want fancier stuff like variadic / commutative pattern matching as in that PR of mine, it's much easier with our own custom implementation than to hack into the library that is not meant to match "subjective" patterns.