Working towards a full e-graph implementation as described by the egg paper.
The type system has a couple of places where e-graphs would've been useful and solved some classes of problems trivially. For example:
Normalization and simplification cannot handle cyclic types due to the nature of their implementation.
Normalization can't tell when two tables or functions are equivalent, but simplification theoretically can albeit not implemented.
Normalization requires deep normalization for inhabitance check, whereas simplification would've returned the never type itself indicating uninhabited.
Simplification requires constraint ordering to have perfect timing to simplify.
Adding a rewrite rule requires implementing it twice, once in simplification and once again in normalization with completely different code design making it hard to verify that their behavior is materially equivalent.
In cases where we must cache for performance, two different types that are isomorphic have different cache entries resulting in cache misses.
Type family reduction can handle cyclic type families, but only if the cycle is not obscured by a different type family instance. (t1 where t1 = union<number, add<t1, number>> is irreducible)
I think we're getting the point!
Currently the implementation is missing a few features that makes e-graphs actually useful. Those will be coming in a future PR.
Pattern matching,
Applying rewrites,
Rewrite until saturation, and
Extracting the best e-node according to some cost function.
Working towards a full e-graph implementation as described by the egg paper.
The type system has a couple of places where e-graphs would've been useful and solved some classes of problems trivially. For example:
nevertype itself indicating uninhabited.t1 where t1 = union<number, add<t1, number>>is irreducible)I think we're getting the point!
Currently the implementation is missing a few features that makes e-graphs actually useful. Those will be coming in a future PR.