It is arguably useful to be able to use e-class ids other than ClassId, so we could provide a module that wraps an e-graph and provides an interface to the e-graph in which e-class-ids are some user-defined type that supports lookups (e.g. instances Ord)
If we want to associate some data with an e-class, but don't want it to live in the e-class data because it might be used very often, or inherently related to the Id rather than the e-class
The user-type for Ids might allow discovering equalities on its own before the e-graph has to, since the Eq instance of the user type might take into consideration more data rather than just being an Int.
TODO
This is mostly motivated by the use of e-graphs in GHC's pattern match checker, where it is potentially useful to use Ids as e-class ids.
Alternatives
We could also say we won't do this as it is a bit ad-hoc and adds complexity, and that
users can have a datatype wrap ClassId with more data they require, and then still use e-class ids and/or
users can instead implement this layer of indirection themselves
Idea
It is arguably useful to be able to use e-class ids other than
ClassId, so we could provide a module that wraps an e-graph and provides an interface to the e-graph in which e-class-ids are some user-defined type that supports lookups (e.g. instancesOrd)Eqinstance of the user type might take into consideration more data rather than just being anInt.This is mostly motivated by the use of e-graphs in GHC's pattern match checker, where it is potentially useful to use
Ids as e-class ids.Alternatives
We could also say we won't do this as it is a bit ad-hoc and adds complexity, and that
ClassIdwith more data they require, and then still use e-class ids and/or